A digital twin as company-wide context for an AI agent - Part 1
Corezoid gave an AI agent access to 2,400 Jira tickets and discovered that writing code was easier than routing work correctly. This article explains how a digital twin helped the agent find the right system, ask for help when uncertain, control costs, and learn from each result.
Series: Inside the Digital Twin (1 article)
- 1A digital twin as company-wide context for an AI agent - Part 1 This article
Routing 2,400 Jira tickets to the right repository, process, or service
An engineer at Corezoid filed a bug about dashboards created through the company's MCP server. The ticket had no component, repository, or owner. An AI agent guessed that the fix belonged in a front-end repository, but its confidence was low. Instead of changing the wrong system, it asked a question in Jira. An engineer replied with the correct backend repository, and the agent continued from there.
This dashboard ticket situation captures what Corezoid learned after giving an AI agent access to about 2,400 open tickets. Writing code was not the hardest part. The difficult part was deciding where each change belonged. Corezoid solved this by building a digital twin of its engineering organization in Simulator.Company . The agent does the work. The twin stores the context, rules, limits, and history it needs.
The missing map
Corezoid Inc. is a digital transformation company. Its products are Corezoid, a process engine on which companies build and run their business processes, and Simulator.Company, a platform for digital twins. The company already had a coding agent. A person labeled a Jira ticket, a pipeline ran the agent, and a merge request appeared. From May through October 2026, it opened 133 merge requests for 116 tickets in 15 repositories. 91% of the tickets it completed ended in a merge. But the system depended on hard-coded routes from Jira projects to repositories. That approach could not work across the whole company. The team looked for a reliable map and found that:
- 94% of open tickets had no component;
- only one repository had a CODEOWNERS file ;
- Jira components meant different things to different teams; and
- some changes belonged in Corezoid processes, Simulator.Company forms, or AWS services rather than Git repositories.
Corezoid had an agent that could write code, but the agent had no understanding of the company it works for.
Building the digital twin
Corezoid reconstructed an initial map from ticket links, commit messages, and ownership history. This produced about 600 routing facts for 211 possible targets. Each fact records a target, a source, and a confidence score. For example, a fact may say that tickets from a particular Jira project usually belong in one repository. A human-confirmed fact has more authority than an inferred one. The twin describes people, projects, repositories, Corezoid processes, Simulator.Company forms, AWS services, and environments. It also stores live Jira and GitLab data, model choices, budgets, limits, and the outcome of every run:
The dispatcher runs the agent when the route is clear and asks a person when it is not. Every answer and outcome goes back into the twin. Corezoid keeps knowledge in the twin rather than pipeline code. People can correct a routing fact or change a limit without editing the pipeline.
AWS Recommendation: Files such as CLAUDE.md or AGENTS.md tell an agent how to work inside a repository. An ontology answers which repository, process, or service owns the work. Teams can start with a routing table in which every fact has a source and confidence score. The AWS Prescriptive Guidance on a semantic layer for agentic AI describes a related architecture. AWS has also announced AWS Context , which maps relationships across organizational data for use by people and agents.
Teach the system to ask
When confidence is low, the dispatcher asks a short question in Jira. It offers numbered choices and accepts either a number or a link. For the dashboard ticket, the engineer replied with a repository that was not among the suggestions. The dispatcher saved the answer as a new human-confirmed fact. Similar tickets can now use that route without asking again.
The rules are simple:
- one comment per ticket;
- no more than three questions;
- numbered options;
- no responses to bot comments.
By 6 November, people had answered 413 of 1,477 questions. The response rate taught Corezoid another lesson: people answer clear questions that require little effort. They ignore vague ones. Not every ticket needs a code change. The dispatcher assigns each ticket to one of four kinds:
Kind | Agent output |
|---|---|
change | A merge request for code, a process, a graph, or a form |
answer | An investigation, estimate, or explanation in Jira |
action | A runbook for a deployment, upgrade, or restart |
human-facing | Handoff to another agent for work such as access or hiring |
The answer category was especially useful. Many backlog items are questions: Why does this behave this way? How long would a change take? Where is this configured? The agent can inspect the relevant code and reply without changing anything, for about twelve cents per run.
The dashboard ticket was classified as a change. Once the engineer supplied the route, the agent opened a merge request with a fix and tests.
AWS Recommendation: A fixed choice such as work type is a classification problem and may not need a large general-purpose model. The Strands Agents team described how an internal Amazon ticketing system used Strands Decider to return a probability for each option. On that workload, it matched Claude Sonnet's performance at about 98% lower cost. The pattern works when choices are stable and low confidence causes the system to ask a person.
Record cost and control the loop
The twin treats budgets and limits like an accountant would. Every run records its cost against the ticket, project, repository, and model. This lets Corezoid compare technical outcomes with spending.
Model selection also lives in the twin. Claude Sonnet handles ordinary work, Claude Opus handles complex and engine-core changes, and Claude Haiku handles small internal calls. All are accessed through Amazon Bedrock. A fallback provider uses the same LiteLLM gateway so its cost is recorded too.
The first code runs used Claude Opus directly and averaged about $10. After ordinary work moved to Sonnet through the Bedrock gateway, an early code change averaged about $2.50. Limits proved as important as accounting. Before per-ticket limits existed, one ticket ran 58 times. Concurrent checks also started 18 runs against a limit of 5. Corezoid decided to implement limits for tickets, projects, spending, and retries.
AWS Recommendation: Application inference profiles in Amazon Bedrock can add project or team tags to billing records. Teams can compare those records with an internal data. Also Guidance for Multi-Provider Generative AI Gateway on AWS shows a reference LiteLLM deployment, if customers want a unified, industry-standard API gateway based on OpenAI API standards.
Learn from failure
A reviewer found that the dashboard fix weakened a check and broke two tests. The agent tried to correct it, but the GitLab runner did not contain the Go toolchain required by the repository. The agent could not run the tests and introduced duplicate test functions. Corezoid fixed the runner so it installs the Go version declared in
go.mod . Failed pipelines now start another agent round with the job logs attached. The next round removed the duplicates, and all tests and security checks passed. The important lesson was that a red pipeline does not always mean the model failed. The problem may be the build image, permissions, model capacity, or orchestration.Other incidents produced the same response:
- A model-generated Jira rule sent 359 security tickets to one approval queue.
- Runs failed after six consecutive capacity errors because no fallback was configured.
- The shared GitLab runner became unavailable and jobs had to move to Kubernetes.
Each incident became a visible rule, fact, or limit in the twin. Corezoid did not hide the lesson in another pipeline branch.
AWS Recommendation: Agent safety depends mainly on permissions and operating limits. Set limits per ticket and per run, and grant write access according to the kind of work. For temporary model capacity errors, Amazon Bedrock Cross-Region inference can distribute requests across Regions. Teams must first confirm which Regions their data may enter.
Results and the next constraint
The dispatcher initially sorted 2,408 tickets. It found 681 ready for the coding agent, 796 that needed more information, and 931 that belonged to other kinds of work. By 6 November, the twin reported:
Metric | Total since launch |
|---|---|
Tickets sorted | 4,147 |
Agent runs / cost | about 3,050 / $1,076 |
Merge requests opened / merged | 836 / 164 |
Answers posted / accepted | 930 / 379 |
Jira tickets closed after agent work | 661 |
Questions asked / answered | 1,477 / 413 |
The scale exposed a new problem. More than 400 agent merge requests were open, and hundreds of tickets were waiting for a human answer. Human review had become the slowest part of the system. Teams need to track review time and queue length alongside cost and success rate. As agent concurrency grows, triage, implementation, review, and merge become separate queues.
AWS Recommendation: The Kiro team reported a similar pattern in How we built a software factory with Kiro Crew to merge 1,000 PRs in a week .
What other teams can apply
Corezoid's experience suggests five lessons:
- Treat routing as a product. Give every routing fact a source and confidence score.
- Let the agent say that it does not know. Below a confidence threshold, ask a short question instead of guessing.
- Keep knowledge outside pipeline code. Store routes, model choices, budgets, and limits where people can inspect them.
- Record every run. Track the decision, cost, outcome, and human correction.
- Limit retries and plan for review. Corezoid allows two agent rework rounds before a person takes ownership.
A team can start with one ticket type and a few repositories. Build a small routing table, add confidence thresholds and limits, then improve it with real outcomes. There is no need to model the whole company before the first run.
A company can reliably hand work to agents only after it describes where the work belongs, what the agents may do, and when they must ask for help.
Any opinions in this article are those of the individual authors and may not reflect the official opinions of AWS.
Series: Inside the Digital Twin (1 article)
- 1A digital twin as company-wide context for an AI agent - Part 1 This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article