This retrospective covers our June 2026 milestone. Published October 30, 2026.
Two interfaces, two engines
Atlas had two ways to investigate an operation. You could ask a question in chat, or a cloud agent could run from its standing instructions and produce intelligence for a dashboard. Both needed to gather context, choose tools, work through the results, and decide what to return. But underneath those experiences, we had separate execution paths. Improving the way an agent worked meant deciding how that improvement should reach each path—and maintaining the differences afterward.
On June 29, we replaced the cloud-agent intelligence processor’s separate agent loop with a headless runner built around the Atlas Chat Graph. The migration was a change to the execution architecture, with a straightforward product consequence: the way an investigation begins no longer needs to dictate which engine performs it. A conversation and a background job can use the same framework while preserving the instructions, access, and output each one requires.
The interesting part was deciding where that shared framework should end. We wanted to consolidate the mechanics of doing the work without erasing the differences between a person asking a question and an agent running an assignment.
The duplication was in the investigation
Take a question such as, “Which shipments need attention?” In chat, the person expects an explanation they can follow up on. A shipment agent working in the background might need to turn a similar investigation into a short list of exceptions or an alert. Before either can produce a useful result, it has to find the relevant shipments, inspect the available information, and determine what the evidence supports. The presentation differs, but much of the work leading to it is the same.
Our previous processor implemented that work through its own agent loop. The new runner passes an assignment into the graph that serves Atlas Chat. The agent’s system prompt defines its responsibility; the runner supplies the goal, organization context, model configuration, and available tools. From there, the graph manages the execution. A custom agent can have a different purpose from a standard supplier or shipment agent without needing an entirely different execution system.
This is the practical reason to share an engine. Planning, tool use, and interpretation are capabilities we expect to keep improving. We want those improvements to be available wherever the work begins. Keeping separate loops would require us to repeatedly decide which fixes, controls, and behaviors should be reproduced in the other implementation.
What a background run brings with it
The new entry point, runIntelligenceViaChatEngine, is the adapter between a scheduled job and the shared graph. It creates the execution context, resolves the model for that agent, selects a tool profile, and binds the tools with the relevant user and organization information. Supplier work and inventory work can therefore use different tool sets even though they enter the same graph. The shared engine receives an assignment with boundaries, rather than discovering an unrestricted collection of capabilities.
Some boundaries come from the environment in which the work runs. A background worker needs an iteration limit, coordination with the job’s lock, and a shutdown signal. It also needs a different response to ambiguity. A person in chat may be available to answer a clarifying question; a scheduled run cannot assume anyone is watching. The cloud runner supplies a defined goal and skips the interactive clarification path, making the quality and scope of the standing instructions especially important.
Each run also has its own identifiers and supplied context. Reusing an engine does not merge every agent’s conversation history or give it another organization’s access. That separation is essential to the design: the graph provides the execution framework, while the caller remains responsible for identifying whose work is being performed and the conditions under which it may proceed.
The dashboard changed the output contract
A conversational answer can explain a finding in prose and wait for the next question. A dashboard needs a result it can render. We made that requirement explicit in the cloud runner: the agent returns a structured array of intelligence cards, using either its configured card schema or the supported standard types. A counter, list, risk flag, chart, and map each require different data. The response is parsed into those structures before it becomes dashboard content.
Two required fields make the relationship to the investigation explicit: selection_rationale explains why the agent chose a card, and data_sources identifies what it relied on. A count of shipment exceptions should be traceable to the shipment information used to produce it; a map should have coordinates from a real tool result. A card’s visual form cannot stand in for the evidence behind it.
One small rule captures the intent of the contract: an empty array is a valid result. If there is no real Atlas data to support a card, the agent is instructed to leave it out. The dashboard should not gain a plausible-looking insight merely because the model has been asked to produce several cards. These requirements still need evaluation and validation, but they give us concrete behavior to inspect instead of treating any well-formed response as a successful result.
A shared engine creates a shared testing problem
Consolidation has a cost. When two experiences depend on the same execution framework, a change in that framework can affect both. A behavior that makes sense in an interactive conversation may be inappropriate for a background run; a stricter output requirement for cards should not accidentally narrow what a person can ask in chat. The caller’s configuration and output contract need to remain visible in our evaluation of the system.
We therefore think about the migration as a cleaner place to improve behavior, not evidence that every workload has become faster or more accurate. Those outcomes require measurement. What the June change establishes is a common path for executing the investigation and a clearer boundary around the things that vary: instructions, tools, context, execution controls, and delivery.
That boundary also makes new product surfaces easier to contemplate. We can ask what information a surface needs, how a person will interact with it, and which actions it should support, without beginning by building another agent loop. The engineering effort can move closer to the experience we actually want to create.
The interface can change; the work should remain understandable
A user should be able to investigate a shipment in chat and recognize the same operation when an agent later surfaces an exception on a dashboard. The formats will differ. The access rules, underlying records, and expectation of evidence should remain coherent. Putting chat and cloud agents on one execution framework is a step toward that consistency.
For Atlas, the migration creates a foundation for work that can begin with a question and continue beyond the conversation. The more ways people have to interact with AI, the more useful it becomes to keep the mechanics of doing the work in one place.
Have an investigation your team repeats? Talk to us about putting Atlas agents to work on it.