Engineering milestone: October 19, 2026. Added to the News archive October 30, 2026.
Opening a shipment should not require the whole catalog
Opening a shipment and researching an unfamiliar trading company are very different jobs. The first has a clear destination: retrieve the record and show it. The second may require finding the right entity, reading several sources, and deciding which specialist data can answer the question. Treating both as the same tool-selection problem adds work where it is unnecessary and can leave deeper research poorly equipped.
Atlas Progressive Tooling is the architecture we are developing around that distinction. Common application reads stay ready. Additional capabilities are discovered when the conversation needs them. Specialist tools can then explain the operations and inputs they support before they are used.
The objective is to make the available tools fit the work in front of the agent while keeping the underlying access rules intact.
Three levels, one conversation loop
The first level is a bounded set of core read and view tools. These are the ordinary actions that should not require rediscovering how the application works: opening a shipment, an inventory item, a document, or a dashboard. Supported direct reads can use the existing route that does not need a model to choose an answer.
The second level is capability discovery. When a question needs more, the agent can load a bounded group of additional tool schemas from the catalog it is permitted to use. Core tools remain available as research moves through those discovery steps. We do this within the existing conversation loop, rather than adding a separate planning model just to select tools.
The third level belongs to the capability itself. A specialist service may first describe its available datasets, fields, identity rules, and query requirements. The agent can use that contract to make a more informed request. Discovery answers which capability might help; the operation contract explains how to use it correctly.
Discovering a tool does not grant permission
A tool name is not authority. The active organization, the authorized catalog, the current mode, and any required mutation approval continue to govern what the agent can do. Progressive Tooling changes when a capability is made available to the conversation; it does not expand what the user is allowed to access.
This separation lets the catalog grow without binding every possible schema into every model call. It also makes the boundaries easier to reason about. A specialist tool still owns its contract. A requested change still follows its execution policy. A research question does not become an unlimited budget for calls simply because another tool can be discovered.
A source failure is part of the answer
Tool access is only one part of a useful research experience. A government source can fail. A company name can refer to several unrelated businesses. A successful query can return only part of a dataset. Those situations need different treatment, and none should quietly become evidence that there is no activity to report.
The engineering work includes provider-failure classification and limits on repeated requests to a source that has already failed. It also keeps an ordinary workspace read from being unnecessarily held behind slower research work. A user who asks to see a record should be able to inspect that record while the rest of the question is still being investigated.
Partial evidence needs a clear label. A retrieved excerpt is not automatically a verified conclusion, and a progress acknowledgement is not itself a finding. The system has to preserve those distinctions as it delivers work incrementally.
We test the answer, not just the call
The pilot work has reinforced a practical lesson: a successful tool call does not establish that the research was good. A comparison has to examine the final answer’s sources, entity resolution, units, coverage, and treatment of uncertainty. It also needs to retain failed and cancelled runs rather than making them disappear from the result.
Our evaluation approach compares ordinary application reads with deeper research cases, using the same deployed revision and model configuration for a controlled comparison. We track when evidence becomes available, when the final response arrives, which discovery steps were used, and where provider waits or repeated calls consumed time. A single fast example cannot establish a general speed improvement.
The architecture and pilot work are the subject of this update. They are not a claim that every research case is solved or that the documented development pilots establish production performance. The release decision depends on preserving research quality as well as making routine work more direct.
Keep the complexity behind the question
A person asking Atlas for help should not need to know how many capabilities sit behind the interface. They should be able to ask a clear question, inspect the evidence, and understand the limits of the result. The engineering responsibility is to make the right capability available when it is needed without losing that clarity.
That is the direction of Progressive Tooling: a smaller immediate working set, deeper capabilities available on demand, and explicit rules that continue to apply all the way through the task.