How specialist agent orchestration anchored to Jira keeps complex coding tasks on spec.
You have probably felt this. You hand a capable AI agent a real piece of work, a proper spec with edge cases and acceptance criteria, and for a few minutes it is sharp. Then it slips, it forgets a decision it made ten minutes ago, rewrites something that was already right, and by the end you are fighting the context window, restructuring prompts, repeating instructions, with the occasional “DON’T DO XYZ” to keep the agent on the right track. The model can clearly write good code. It is just straining to hold the whole thing in its memory at once, and losing its grip. (And this is costing you time and tokens).
Why does the agent drift from the spec?
An agent reasons inside a window of working memory. The architecture, the product intent, the UX, the test the agent actively writing, all of that lives in that one space. A small task fits. A real feature does not, and as the context window fills the agent quietly trades away earlier decisions to make room for new ones. Explicitly stated instructions start to be ignored. The first sign you get is notice the agent has broken a rule you need to reinforce.
A bigger model or longer context window raises the ceiling but does not change the fundamental limitations. Attention is finite and shared across every token, models reliably lose the middle of a long context (the “lost in the middle” effect), and each step conditions on the last, so an early drift compounds. A bigger window just moves the wall further out.
How to design a multi-agent system that stays on spec
Give every agent their own job to prevent context window drift
Think about how a strong team ships code. Nobody holds the whole project in their head. One person maps the codebase, another writes the feature, someone owns the look, someone checks the order so two changes do not collide. We designed our agentic system to work the same way. The problem is broken apart and handed to specialists, each with one job, small enough to fit into the context window with headroom to reason.
Our core agentic team
| Agent | What it owns |
|---|---|
| Code Cartographer | Reads the codebase, maps the packages, finds the patterns and seams to build into |
| Engineering Alchemist | Audits code architecture |
| Visual Stylist | Shapes the interface so it matches the intent of the spec |
| Ticket Auditor | Keeps the work in the right order so parallel changes never collide |
| Review Agents | Code quality reviews, Runs the finished app, video records the walkthrough, attaches the proof |
The full cast has a larger cast of specialists You can start with a few and add more when you hit a coordination bottleneck. Balance with the choice and strength of your underlying models.
Improve stability and agent cohesion by anchoring them to Jira
Using the team of specialists with local markdown files exclusively to manage both the plane and state was unstable. The agents were capable, but work was attempted out of order, progress was impossible to measure, and if the session accidentally ended it was difficult to resume with no bearings to where we were in the plan. In order to sequence tickets and organise order of work, we needed a shared tracking system.
Why Jira? The board is more than a tracker.
- Jira is a dependency DAG. Issue links draw the critical path on their own, so a scheduler knows what is safe to run in parallel. Nothing starts before its prerequisites are done.
- The work item is the prompt. The job description plus acceptance criteria is a self-contained, versioned context packet, which is what we mean by “work items as prompts.”
- State, audit, and humans inbuilt. Jira has Atomic status transitions that handle concurrent agents, history gives you an audit trail, and a person can reprioritise in the same board the agents read, keeping a human in the loop to offer judgement when an agent can’t.
| Local markdown files | Jira board | |
| Work ordering | Implicit | Explicit |
| Work progress | No way to determine progress, making it difficult to resume work | Durable state accessible at all times, easy to measure progress and resume work |
| Assignment | Unclear who (agent or human) owns each task | Assignee field per ticket; visible to everyone |
| Scale | To-do-list in context drifts; too large for a single window | Board handles hundreds of tickets without degrading |
| Comments & tagging | No native support; adding metadata pollutes the spec | Comments, labels, and history are separate from the work description |
| Collaboration | No way to collaborate, comment, or update ordering without polluting the spec | collaboration easy from comments to updating the priority |
| Audit trail | None unless you build it | Complete history of work |
| Automation & workflows | No built-in triggers — you write all the glue yourself | Workflow rules and webhooks can fire on work transitions, triggering next steps or new agent work |
Orchestrate with a daemon, not an agent, for reliable scheduling
One way to orchestrate is to just have one smart agent run the show invoking other agents / subagents. We tried it. One risk is that the orchestrator is itself an agent, the thing meant to keep everyone on track drifts too. There is no anchor left to pull it back, so a wobble at the top compounds worker under it. We still have an orchestrator agent, but some of the work is inbuilt into the tooling (the daemon) which is deterministic, offloads context otherwise used to do the same work via inference, and in turn also reduce harnessing overheads on the initial boot.
A daemon does not drift, because it is not reasoning (which also means it’s not burning tokens). It is fixed code that does the same thing every tick: read the board, find tickets whose blockers are done, dispatch them. Same input, same decision, every time.
⚗️ The daemon is gravity. Workers can wander mid-task, but the Jira board is the ground state and the daemon’s next read pulls the system back to it. However a run ends, the next decision comes from durable board state, not a context window. The system converges instead of compounding errors.
Could a good enough model orchestrate reliably? Maybe, eventually. But intelligence trades against predictability and cost, and scheduling needs neither creativity nor a big context, only to be right every time. So we spend agent intelligence where judgment matters, the work itself, and try to use cheap deterministic code own the coordination.
How to build your own team of specialists
Four steps:
1. Anchor everything to a Jira board
Put the plan on a board: one ticket per unit of work, with issue links for dependencies. The links are your dependency graph, so you never write a planner. This board is now the single source of truth for what to build and in what order.
2. Run a daemon that watches it
Write a small daemon (a cron loop is enough) that polls the board for tickets in To Do whose blockers are all Done. That query is your scheduler. For each ready ticket it moves the ticket to In Progress (the lock, so nothing runs twice) and hands it to the agent.
3. Give the agent personas to call
List the teammates you wish you had, one job each, and make each a sub-agent the parent can call. Start with three: a Designer that owns product and UX intent, a Builder that writes the code, and a QA that verifies it against the spec. Pass the sub-agent only the ticket description and acceptance criteria. A fresh window and one job is what keeps it from drifting.
4. Report back and let the loop advance
When the sub-agent finishes, it comments its diff and walkthrough on the ticket and moves it to Done. On the next tick the daemon sees the newly unblocked tickets and dispatches them, so the loop runs itself. You get the audit trail, the order, and proof you can watch for free, all from the board.
Keep a person in the loop. The win is not that the reviewer disappears, it is that hours of investigation turn into minutes of looking at something already done.
See it run
A spec goes in, a working application comes out, and every step is traceable in Jira.
