Multi-Agent Systems Need More Than a Prompt
DEV Community

Multi-Agent Systems Need More Than a Prompt

Most multi-agent demos look simple. An agent receives a request, delegates a few tasks, calls some tools, and returns an answer. Then you try to use the same system for real work. Suddenly, the important questions are not about the prompt:

  • What context did each agent receive?
  • Which workflow or tool ran?
  • Where is the output from the previous step?
  • Why did the process stop?
  • Is the system waiting for a person?
  • Can we continue without starting again?
  • How much time and money did each step consume?

If the answers are scattered across chat sessions, terminal logs, and database records, the system becomes difficult to trust. This is the problem we are working on with Heym.

A board where cards do the work

In a traditional Kanban board, cards describe work that people need to complete. In Heym's Agentic Kanban Board, a card is the work. Each column can contain an ordered chain of AI workflows. Moving a card into a column starts that chain automatically. Moving a card from Backlog to Planning is no longer just a status change. It is an execution event.

The Planning column might:

  • Analyze the request.
  • Retrieve relevant context.
  • Ask clarifying questions.
  • Produce an implementation plan.
  • Wait for human feedback.

The Development column can then receive the same card, including the plan and the human's answers, and start a different workflow chain. The card becomes the handoff between agents, workflows, models, and people.

Persistent context instead of repeated prompts

One of the hardest parts of building multi-agent systems is preserving context across steps. A Heym card carries:

  • The original request
  • Comments and human responses
  • File attachments
  • Previous workflow outputs
  • Movement and activity history
  • Execution results
  • Error states

Every new workflow receives the accumulated context. This means you do not need to copy the same information into another prompt or invent a custom protocol for every agent handoff. The card acts as shared memory for the process. Different columns can use different models, tools, and workflows while operating on the same persistent job.

Build with small, inspectable workflows

A production agent system is easier to understand when it is composed of small workflows with clear responsibilities. For example, a feature development board could use:

  • A planning workflow that asks clarifying questions
  • A research workflow that retrieves technical context
  • A specification workflow that creates acceptance criteria
  • A coding workflow powered by Codex
  • A review workflow that checks the result
  • A publishing workflow that creates a pull request

Each workflow can be opened and inspected on Heym's visual canvas. The control flow is explicit. You can see which workflow runs in each column, which tools are available, where approvals happen, and how outputs move into the next step. This is what we mean by visible decisions. It is not hidden model reasoning. It is visible workflow routing, tool activity, retrieval results, approvals, and execution state.

Run the system by moving work forward

When a card enters a column, the workflows attached to that column run sequentially. Each successful workflow appends its output to the card before the next workflow starts. The card communicates its current state visually:

  • Pulsing amber means the workflow is running.
  • Static amber means the workflow is waiting for human input.
  • Green means the chain completed successfully.
  • Red means a workflow failed and the remaining steps were stopped.

This makes the board useful for both technical and non-technical team members. A developer can inspect the execution details, while someone from product or operations can understand whether a job is running, blocked, completed, or failed.

Keep humans at the right points

Full autonomy is not always the goal. Some decisions need context that only a person can provide. Others need explicit approval because they affect customers, production systems, or external services. Heym workflows can pause for:

  • Human-in-the-loop reviews
  • Agent tool approvals
  • Clarifying questions
  • Codex follow-up questions

The execution state is persisted while the card waits. Once someone answers or approves the request, the workflow resumes from the same point. The rest of the column's workflow chain continues automatically. This is especially useful during planning. A planning workflow can enrich a request and ask questions. The card stays in Planning until someone responds in the comment thread. That response becomes part of the card's context and releases it to the next stage. If the plan needs more work, you can run another follow-up round without losing the previous discussion.

Debug the workflow, not just the final answer

When an agent produces the wrong result, the final response rarely tells you enough. You need to inspect the execution. Board runs in Heym are connected to the same execution history and tracing system used by other workflows. You can inspect:

  • Per-workflow inputs and outputs
  • Agent and tool calls
  • Errors and failed steps
  • Execution timing
  • Token usage
  • Estimated model cost
  • Human approval states
  • Previous attempts

This makes it possible to understand where the system failed without replaying the entire process from memory. The board shows the operational state. The execution traces show the technical details behind it.

A simple planning loop

A useful first workflow looks like this:

  • Create a card containing a feature request.
  • Move the card into Planning.
  • The planning workflow analyzes the request and writes clarifying questions.
  • A human answers those questions in the card's comments.
  • The card moves into Development with the answers included in its context.
  • Development workflows run automatically.
  • Successful steps move the card toward Done.
  • Failures and approval requests remain visible on the board.

This is a small loop, but it contains the important parts of a production agent system:

  • Work intake
  • Context assembly
  • Agent execution
  • Human feedback
  • Persistent memory
  • Failure handling
  • Observable results

You can expand the system by adding new workflows to the chain instead of turning one prompt into an increasingly complicated block of instructions.

Agents need an operating surface

Prompts are part of an agent system, but they are not the system. A reliable multi-agent workflow also needs memory, control flow, approvals, execution state, and observability. That is what we want the Agentic Kanban Board to provide: a shared surface where people can see what agents are doing, understand what happened, and step in when needed.

You can read the complete technical walkthrough and import the starter planning workflow here: Agentic Kanban Board: Loop Engineering for AI Agents

Heym is source-available and self-hostable. You can also explore the repository on GitHub. Build, run, and debug multi-agent systems with visible decisions, memory, approvals, and execution traces.

Comments

No comments yet. Start the discussion.