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):

1. 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.

2. 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.

3. 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.

4. 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

1. Slack request arrives.
2. Grace asks clarifying questions and performs triage:
   • complexity,
   • importance,
   • whether she can complete it in one shot.
3. If feasible, she spins up Cursor to implement:
   • prompts Cursor with codebase context,
   • generates a PR,
   • posts PR for human review.
4. 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