One Jira Ticket Through an Org of AI Agents: The Architecture

A developer writing as Murthy G. outlined an architecture for routing a single Jira ticket (PLAT-412, rate-limiting a public /export API) through an organization of AI agents, from a board-level quarterly goal down to merged code. The design places agents in one layer while budgets, permissions and approvals are enforced by plain software rather than a model, with each seat defined by a consistent card covering inputs, decisions, handoffs, escalation triggers and scoring. Key mechanisms include mapping every acceptance criterion to a concrete test, batching blocking questions against a human-minute budget, and estimating agent work with P50/P90 cost and wall-clock fields in addition to story points.

Following a single story from the board's goal to merged code, through PM clarification, estimation, budgets, risk gates and scorecards. In the last post https://dev.to/murthyg/what-if-your-ai-agents-had-an-org-chart-3a03 I sketched an org chart for AI agents: seats that a human or an agent can fill, capacity split down by percentage, probation and benching, and a human overseer on every agent seat. The most common question was: "OK, but what actually happens when a ticket shows up?" So this post follows one ticket all the way through. It's PLAT-412: "Rate limit the public /export API" , and we go from the board's quarterly goal to merged code in production. 👉 Interactive diagrams: probita-ai.github.io/agent-org-model/architecture.html https://probita-ai.github.io/agent-org-model/architecture.html Agents run in one layer. Everything that limits them is plain software. No model sits in the decision path for budgets, permissions or approvals. | Level | Seat | Hands down | |---|---|---| | Board | Humans | $10,000/month, goal "−50% API incidents" | | CEO | Human + copilot agent | Engineering 40% $4,000 | | CTO | Human | Epic PLAT-EPIC-40, Platform crew 60% $2,400 | | PM | Human + PM-assist agent | PLAT-412 with 3 acceptance criteria | | Platform Lead | Agent, L2 suggests, human approves | Assignment + brief to coder-1 | | Coder | Agent, L3 | PR, 5 points, P90 $28 | | Tester | Agent, L3 | Report + 3 tests the coder didn't write | | Reviewer | Agent, L3, 10% human-sampled | Approval | | Release | Lead prepares, human approves | Staged flag rollout | | HR / Finance | Staff agents | Actuals, scorecard update | Every seat uses the same card: what comes in, what it decides, what it hands out, when it escalates, and what it's scored on. That consistency is what makes it possible to swap a human for an agent or back in one field. This is where most people's mental model of "an AI coder" is too thin. "Read ticket, write code" skips the parts that make human engineers good. The single most useful rule is in phase 2: map every acceptance criterion to a concrete test. Any criterion that can't be mapped is marked ambiguous. That one check catches most unclear tickets before anyone writes code. The coder also has hard stop rules , enforced by the orchestrator rather than the prompt: PLAT-412 says "limits configurable per plan tier." Per user? Per org? Per API key? The ticket doesn't say. Which is realistic. The coder sends one batch of questions, not a drip: type: question batch estimated pm minutes: 4 questions: - id: q1 blocking: true text: "What should the limit be keyed on?" options: a: "API key matches how /export authenticates " default b: "Organization" c: "User" why: "Changes the Redis key design and what customers see." - id: q3 blocking: false text: "Build the dashboard, or emit a metric ops adds?" options: a: "Emit metric only" default b: "Build the panel +2 points " The rules: And the PM picked organization , not the default. That's the whole argument for asking instead of assuming. The answer is recorded as a decision , and decisions are injected into every later step, so the reviewer doesn't "fix" it back. Every question also draws from a human-minute budget . The PM publishes 300 minutes a week for this crew. Agents are scored on human minutes per point , so lazy questions have a cost. A human team estimates in story points. Agent work needs more, because the scarce resources are different. | Field | Why | |---|---| | Points | One relative scale for humans and agents | | Agent cost P50 / P90 | P90 becomes the budget reservation | | Wall clock | Mostly waiting on humans and CI | | Human minutes | Often the real bottleneck | The method: base P50 weighted median of similar jobs $12.00 × 1.15 external call with no cache × 1.05 customer-facing flag + rollout P50 ≈ $14.00 × 2.0 spread factor from this agent's own history P90 $28.00 Actual: $13.20 , inside P90. That feeds back into calibration : an agent whose P90 holds about 90% of the time earns a tighter spread factor. One that always says "13 points, P90 $200" is safe but useless, and loses score too. To stop point inflation, the reviewer assigns "actual points" after the fact. There are split rules too. More than 8 points, a P90 over $40, more than 2 services, or a migration plus a behaviour change means the coder must propose a split to the PM. When the lead agent planned the sprint, dollars fit fine $980 P90 against $1,020 plannable . PM minutes didn't 410 against 300 , so a ticket was dropped. That changed the whole design. Human attention is budgeted the same way as money : reserved per job, metered and reported. The useful question about an agent isn't "how fast is it?" It's "how many human minutes does each point of its work cost?" That number decides how many agents a team can actually supervise. The biggest weakness of deep agent hierarchies is context loss. The fix is briefs : structured packets where each level adds and never just forwards. Briefs link to sources rather than pasting summaries, so the receiver can always go to the original. Capacity. Shares flow down by percentage. Each job also reserves its P90. It pauses at 80%, and at 100% the gateway refuses calls. Unused budget goes back on close. Risk gates. Every tool call is classified, not every agent. Reading a repo is low risk and allowed. Opening a PR is medium and sampled. A migration or a prod flag change is high and needs human approval or a narrow, expiring permit. Secrets and pushing to main are never allowed for agents. Scorecards. Real outcomes outweigh another model's opinion: escaped defects, CI results and human overrides weigh more than reviewer-agent verdicts. On this ticket, the probation agent ran in shadow mode, keyed the limit by API key, and ignored the PM's decision. Its score was 0.58 against a 0.75 bar, so it stays on probation. Nothing it produced left its sandbox. Bottom up, as the first post argued: Full diagrams: architecture page https://probita-ai.github.io/agent-org-model/architecture.html · Text version: docs/architecture.md https://github.com/probita-ai/agent-org-model/blob/main/docs/architecture.md · Repo: probita-ai/agent-org-model https://github.com/probita-ai/agent-org-model Which of these phases would you trust an agent with today, and which would you keep human?