Summary of "Demo: The Human + AI-Agent Dev Team"
Overview (speaker + product context)
- Henrik (Abundly) explains how Abundly uses an internal AI-agent workflow across the full product development lifecycle—not just coding.
- Abundly’s product is described as an operating system for AI agents: a place to create, run, and manage “digital colleagues.”
- The team is small but ships a new product version every day, with many integrations and a large codebase—presented as enabled by pervasive AI assistance.
Core technological idea: “agents” replacing bottlenecks
- Teams initially used GenAI like “copy/paste” (ask a model → paste changes back into the editor).
- Over time, tools/models became more “agentic” (able to take on larger tasks and be triggered by events like Slack messages).
- As coding scales, the bottleneck shifts upstream/downstream to:
- deciding what to build,
- design and planning,
- deploying to production.
- Abundly addresses this by building a system of multiple specialized agents that work together.
Agent system inside Abundly
1) Backlogger (upstream: intake → tickets)
Problem addressed
- Slack discussions are “messy,” and manual ticket writing causes slowdowns and context switching.
- Without automation, teams may create vague/low-quality tickets or forget issues.
What it does
- Converts Slack threads → clear Kanban tickets with:
- good titles/descriptions,
- screenshots,
- links to the Slack thread.
- Populates the appropriate column on the Kanban board.
- Triage weekly; not every Slack item becomes a ticket (sometimes teams implement directly).
Implementation approach
- Created as a new agent (“backlogger”).
- Enabled integrations like Slack and Notion.
- The agent initially wrote its own workflow instructions; Henrik’s team then edited them.
- It was “unleashed” on Slack and improved through iterations.
Noted technical hiccup
- User mapping: the ticket needs the correct reporter, requiring mapping Slack users ↔ Notion users.
- The agent creates/maintains its own mapping database and updates it as it learns.
Benefits
- Saves time creating tickets.
- Biggest gain: reduced context switching and faster decision-making during triage (developers get well-phrased, actionable tickets).
Adjacent capabilities
Even with its focused purpose, it can also:
- answer questions like:
- who’s working on a feature,
- what security work is in progress,
- move board items between states (e.g., done → closed).
2) Releaser (downstream: daily releases)
Problem addressed
- Releases used to happen 1–2 times per week with manual steps (release notes, PR setup/approval admin).
- As velocity grew, shipping became a bottleneck.
What it does
- Goal: release every day.
- Operates using four triggers (scheduled + event-driven):
-
Weekdays 1:00 PM: prepares release
- Uses GitHub to find changes since the last release.
- Creates a PR with new features and links to underlying PRs.
- Creates a documentation PR to update docs.
- Posts to Slack asking for approval.
-
Human-in-the-loop approval
- If the PR isn’t approved by 1:37 PM, it posts an “angry rant” in the dev Slack channel (intentional personality).
- Approval is required before production merge.
-
On PR approval
- Merges PR to ship production.
- Merges docs PR and updates the change log.
- Posts to internal “product releases” Slack channel with:
- high-level summary,
- a thread for details.
-
Fridays 2:02 PM
- Posts weekly release summary to the product channel.
Lessons learned (technical/process)
- Break down instructions per trigger using separate documents for manageability.
- Token efficiency issue with GitHub API:
- GitHub API responses can be too large, waste tokens, and confuse the agent.
- The agent wrote and maintains custom scripts (e.g., “get my PRs”) to fetch exactly what it needs.
- Agents build on each other:
- Releaser generates change logs/release notes using commit comments and PR descriptions written by Cursor.
Benefits
- Releases truly happen every day, reducing:
- backlog/code waiting,
- merge conflicts from stale PRs,
- process waste.
- Improves stakeholder communication via better release notes/change logs.
Adjacent capabilities
- Can create hotfix/extra releases.
- Can support newsletter needs by summarizing release highlights.
3) Grace (end-to-end: stakeholder request → triage → design → PR)
Purpose
- A higher-level, more “colleague-like” generalist workflow agent.
- Named after Grace Hopper, referencing a “debugging” / moth story.
Core capabilities
- Can use Slack, GitHub, Notion.
- Can create/manage Cursor agents via the Cursor Cloud API.
- Communicates with other agents (Backlogger/Releaser) by connecting to them.
Typical workflow
- Slack request arrives.
- Grace asks clarifying questions and performs triage:
- complexity,
- importance,
- whether she can complete it in one shot.
- If feasible, she spins up Cursor to implement:
- prompts Cursor with codebase context,
- generates a PR,
- posts PR for human review.
- If not feasible alone:
- may create a Notion ticket (using Backlogger),
- and later humans implement with Cursor assistance.
Important judgment principle
- Grace avoids deep/uncertain engineering tasks; humans handle complex work with AI assistance.
Execution example (scenario: vague “star feature”)
- Grace asked what “starring” refers to (agents, documents, conversations).
- Checked whether related tickets already existed by querying Backlogger.
- Asked Cursor to analyze implementation scope and UX/design tradeoffs.
- Determined it was low-risk but needed some UX questions; then:
- completed those,
- told Cursor to build,
- created a high-quality PR including:
- clear problem statement,
- tradeoffs,
- testing checklist.
Agent design / context management
- Grace maintains internal structured “memory/state” artifacts:
- Errands database (what she’s waiting on: humans/Cursor status),
- Dashboard for human-readable status,
- recurring-task scripts for token efficiency (e.g., updating statuses),
- “Skill documents” (how to use Cursor Cloud API, etc.),
- general context documents (company/process info).
- Many of these artifacts were created/maintained by Grace after launch.
Retrospective behavior
- After her first day, Henrik asked for a retrospective.
- Grace reviewed logs/diary and wrote:
- what worked (pipeline wiring Slack → Cursor analysis → Notion ticket → PR),
- what didn’t (asking questions before doing homework),
- concrete improvements.
- She then updated her instructions/scripts/docs accordingly.
Benefits
- Offloads dev team work (doesn’t replace humans).
- Provides a “fast lane” for stakeholder requests.
- Humans stay in control:
- humans write/adjust instructions,
- review/approve PRs,
- choose whether to act.
Key takeaway / “system effects”
- The video emphasizes a compounding ecosystem:
- Backlogger cleans Slack → tickets
- Cursor writes clean code/commit descriptions
- Releaser ships daily and produces release notes from those descriptions
- Grace ties stakeholder requests end-to-end and triggers the right agents
- Building is described as iterative (“grow agents”), not one-shot.
- Future outlook: agents will expand capabilities over time, but with the same underlying principle—humans and agents work as colleagues.
Main speakers / sources
- Henrik (Abundly) — primary narrator and developer/operator of the internal agent system.
- Other referenced systems/tools (not speakers):
- Slack, Notion, GitHub, Cursor, Cursor Cloud API
- the Abundly agent platform
Category
Technology
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...