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.

Authors: Dmitry Makarichev (CTO, Corezoid Inc.) and Max Ivashchenko (Senior SA, AWS)

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.

The dashboard ticket exposed a routing problem across Corezoid’s backlog. Deciding where each change belonged was harder than writing the code. 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 Jira label triggered a pipeline that ran the coding agent. The agent then opened a merge request. 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 lacked a reliable map of Corezoid’s systems and owners.

Building the digital twin

Corezoid reconstructed an initial map from ticket links, commit messages, and ownership history. This reconstruction 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.

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 November 6, 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:

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 dispatcher classified the dashboard ticket as a change. Once the engineer supplied the route, the agent opened a merge request with a fix and tests.

Record cost and control the loop

The twin stores budgets, limits, and the cost of each run. Corezoid records each run’s cost by 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. Corezoid accesses all three models through Amazon Bedrock. Corezoid accesses its fallback provider through the same LiteLLM gateway and records those costs 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.

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. In the next round, the agent removed the duplicates, and all tests and security checks passed. A failed pipeline can point to problems with 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.

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 November 6, the twin reported:

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.

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 the agent two rounds of rework 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.

Original article on AWS Builder Center