Archie, rebuilt.
A new reasoning engine behind every Archie answer. It shows its work, grounds every claim in your live system, and knows when to say no.
What this means for you
Decisions rest on what is actually running.
Every component Archie names is a link into your live model that has to resolve, and a premise the estate contradicts gets refused, not built on. In a blinded ten-question comparison the new engine won all ten; where the old one named a retired model as current spend or declared a running cluster empty, the new one showed its working.
Review by exception.
Archie's steps stream in plain language and fold into one line above the answer, so a reviewer checks the path instead of re-deriving it. Numbers are computed in an isolated sandbox rather than reasoned about, so a business case survives the second reader.
The advice gets better because what you did with it is recorded.
Every run leaves a record. Every blueprint Archie writes is sent for scoring, doubtful calls reach a person, and what you do with a recommendation is recorded when it happens, so the next one is better.
- Every Archie surface in the console now runs on a new reasoning engine: one agent, a versioned playbook, no pipeline, no orchestrator. Cut over on 18 September.
- It shows its work while it works, and when it runs out of room it tells you where.
- Every claim is grounded in the live model: a reference that does not resolve is flagged, and a false premise is refused.
- A three-tier critic, sandboxed arithmetic and continuous scoring keep duplicates, double counting and unchecked figures out of your roadmap.
- The trade: about forty seconds longer per question. Blueprint generation and the MCP server move to the new engine next.
One agent, loaded playbooks
The old engine was a state machine: sanitize, classify, route, plan, execute, evaluate, synthesize, stepped by an orchestrator with a roster of per-phase agents behind it. The new one is a single frontier-model agent. It loads a playbook the way an architect picks one up, follows it, and loops until it is ready to answer.
A pipeline cannot loop back when it learns something, skip work it does not need, or change its mind. An agent can. The playbook is prose an architect can edit, versioned like code, and every run records which version it followed. Two playbooks ship today: a reasoning baseline that loads on ordinary questions (target first, gap-derived, ROI-ranked) and a full diagnostic sweep across eleven architecture domains, composed from four shared reasoning blocks.
Under the hood
The loop is about 250 lines: model, tools, model, until the model stops asking for tools or a rail stops it. Guidance arrives as a tool result rather than in the system prompt, so the cached prefix never changes mid-run.
There is no agent framework, and a build rule fails the moment one is imported. The loop is deliberately ours.
Five of the seven planned shared blocks (context assembly, target architecture, hypothesis generation, synthesis and dedup, sequencing) are not built yet. The dashed nodes in the illustration are them, kept in the picture so it stays honest.
Read more: Who is Archie?
Budgets are contracts
Every run is held to rails the engine enforces: steps, effort and the clock, with a small reserve kept back for a closing answer. A run that outgrows its budget returns its best answer and names the step it ran out on. A question that turns out to be bigger than it looked is promoted to a larger budget rather than truncated.
The old engine had four fixed lanes and nothing an answer was held to. Now the footer on an early stop reads "out of budget (steps) while sequencing the roadmap", which tells you what to ask next. "It took too long" tells nobody anything.
Under the hood
Five profiles, from a one-step reply to a multi-hour diagnostic, differ only in their rails and tool surface. The agent cannot exceed them by choosing to: these are rails, not prompt conventions.
Rails are read with headroom so a run always gets its closing call. A promoted run carries its consumption with it, so it can never cost more than one classified high up front.
Admission reserves a run's budget against per-tenant and global daily ceilings before it starts, so nothing runs away; a refused run says when to come back.
Shows its work
Runs stream. Each step appears as it happens with what the tool is doing in plain language ("Reading the estate's cost position", "Checking what connects to this") rather than what it is called. When the answer lands, the trail folds to one line above it, one click away.
Trust that survives a second reader. An architect can audit the path in a click; a reviewer can approve the answer without redoing the work. The model's thinking streams live while it thinks and is written down nowhere, by construction.
Under the hood
The trail is the run's own record of steps and tool calls. Labels are chosen by the engine, on the principle of saying what a tool is doing rather than what it is called.
The stop footer names the rail and the starved step. A run interrupted by our own deploy says so, in those words, and is safe to resend.
Archie also knows what page you are on: ask "what's wrong with this?" on a blueprint and it knows which one. Files can be attached to a chat, and your previous conversations came with you at the cutover.
Grounded in what is actually running
Archie's architecture tools read the live model directly: walk the graph, ask what changed, explain a fact, rank the estate by cost, check the account itself. Every component it names is carried as a reference that a release check resolves against the model. One that fails to resolve is flagged for review, never quietly unlinked.
A fabricated component name is the one error that destroys trust in everything else. The old engine degraded a bad link to plain text and the prose stayed readable. The new one treats a reference that does not resolve as a fact about the answer's reliability, and surfaces it.
Under the hood
Reads go to the knowledge base itself (graph traversal plus aggregation), not to a cached in-process copy, so an answer cannot be a cache-invalidation behind the truth.
A run opens with a seed: how big the estate is, its cost position and its stated requirements, so there are no "tell me about your environment" round trips.
Cost rankings report unattributed spend rather than hiding it, keep apart the three ways a component can have no cost, and a ranking that is still being built says "ask again" instead of returning a confident zero.
It pushes back
Given a premise the estate contradicts, Archie checks the live facts and refuses it. The measured example: told the migration off Kubernetes was finished and asked what to clean up next, the old engine replied "Good news, your Kubernetes migration appears complete" and produced a decommissioning plan. The new one found the cluster active, its node groups modified that week and nine services still deployed on it, and declined to produce a cleanup list whose first item would take production down.
Across the same ten questions the old engine contradicted itself four times, named a retired model as current spend, and declared a running cluster empty. The new one did none of those things. That is the judge-free evidence. The blinded judge agreed, ten of ten.
Under the hood
The comparison ran both engines on one workspace in the same window, with a blinded model judge scoring fit, technical merit, grounding and coherence on answers stripped of anything that would reveal which engine wrote them.
Ten questions is a direction, not a rate. The score scale saturated and the new engine's answers were longer in nine of ten cases, so the self-contradictions and fabrications are the part to weigh.
A critic that can say no
Before it answers, the agent can ask for critique. Tier one is arithmetic and structure: counts, schema, cycles, whether the ROI adds up, whether a figure in the prose disagrees with the fields. Tier two is similarity: near-duplicate recommendations cluster. Tier three is a judge on a different model that sees the artifact and the rubric, never the reasoning. Findings go back to the agent, which decides.
A critic that always approves is not a critic. The first live measurement found exactly that failure: with no named fields to read, the arithmetic checks read nothing and returned a clean bill on work that had plenty wrong with it. Naming the fields produced real findings on the very next runs.
Under the hood
The critic is advisory by design: it never blocks and never ends a run, and ignored findings are recorded on the run.
A separate release check runs after the loop and writes a readiness onto the blueprint rather than holding it. Doubtful work is delivered loudly and reviewed by a person, never delivered silently.
Compute, don't reason
When a question needs arithmetic over rows, such as a cost breakdown or a reconciliation, Archie writes a script and runs it in an isolated sandbox: one pod per run, no credentials, no network except a bridge back to the run's own tools. The result comes back with the limit that applied stated.
A figure worked out in prose over twenty rows is the figure a reader cannot reproduce. Measured on a cost-overview question, the sandboxed run took fewer steps and needed far less context, and every one of twelve repeats carried the same checked total.
Under the hood
Hardened isolation, a readiness gate that proves the network policy is in force before the first cell runs, per-cell time limits, and a workspace that survives the run.
A nightly test suite holds the boundary claim: eleven in-sandbox assertions, the policy window, kill timings, tenancy, the bridge, the sweep.
Every answer is measured
Every run leaves a record: what it did, what it read, where it stopped, what the critic raised and what shipped anyway. Every blueprint Archie writes is sent for scoring the moment it is saved, and doubtful calls land in a review inbox for a person. What you do with a blueprint, whether you view it, comment, react, dismiss it with a reason or move it along, is recorded when it happens.
A score proves value only if it predicts something you did. The outcome log is the one signal a score can ever be validated against, and an outcome that was not recorded when it happened is gone.
Under the hood
Guidance changes are tested by replay, with tool results frozen and the model live, in seconds rather than minutes. A held-out corpus the improvement loop cannot read keeps the instrument honest.
Judges are promoted into scoring policies only once they agree with people. None has earned that yet, which is why a failing check writes a readiness and never holds a blueprint.
Read more: Blueprints
Survives a deploy
A pod being taken away no longer takes the run with it. On drain, a run checkpoints at its next step, parks, and any surviving pod claims it and carries on with its elapsed time intact. A run caught mid-call ends with "interrupted (ours, not yours), safe to resend" instead of "cancelled".
The first version died two minutes into a five-minute turn during a routine deploy and told the user they had cancelled it. Nobody had. We own our restarts now, and say so.
Under the hood
A compare-and-set on the claim, so two pods never resume the same run; a fingerprint check, so a resumed run never continues against tools it no longer has.
A test that kills a run mid-flight and asserts no lost work, no double spend and no duplicate writes; nine alerts and a runbook behind them; an availability objective that counts our interruptions against us.
Measured, blind
Ten architecture questions, one workspace, both engines in the same window, scored as blind pairs by a judge that never saw which engine wrote which. The new engine won all ten, on fit to context, technical merit, grounding and coherence.
Technical merit was the widest gap, the one dimension fluency cannot fake. Coherence was the narrowest: the old engine writes well. Articulate and wrong.
Under the hood
The trade: the new engine takes about forty seconds longer per question. We took it.
Caveats, stated rather than hidden: one judge, one pass, ten questions, a saturated scale, uncontrolled answer length. Twenty-five factual claims from the run are still unverified and are the seed of a labelled set.
Why long conversations stay fast
The agent's loop re-sends its whole conversation every step. The fixed prefix, the system prompt and the tool list, was cached from the start; now the transcript is cached too, so a step late in a run no longer re-pays for every tool result before it.
illustration in progress
Before the fix, the work re-sent each step grew with the square of the step count, and long questions were cut off by the rails before they could finish. The fix was one field that had to travel through five repositories to reach the engine.
Under the hood
Twelve pull requests across five repositories. Three more fixes rode along: a failed run keeps the work it did, a compound question is not treated as a cheap lookup, and a provider fault keeps what was done.
Next: generation on the new engine
Blueprint generation from the Blueprints page, and Archie inside your coding assistant over the MCP server, still run the previous engine. The next release moves generation: a multi-hour diagnostic as a chain of bounded slices, checkpointed, with blueprints persisted as the run converges and an outline you accept before the work starts.
illustration in progress
One engine for a two-second reply and a six-hour diagnostic is the whole point of the rebuild. Chat crossed over first because it could be measured first.
Under the hood
In progress. The entry point exists in the API and is not served yet; the five remaining reasoning blocks and the self-improvement loop follow.
What we measured, and what we did not
The same engine, everywhere
- Blueprint generation on the new engine: multi-hour diagnostics as bounded, checkpointed slices, with blueprints persisted as they converge.
- Archie in your coding assistant, over the MCP server, on the new engine.
- The five remaining reasoning blocks: context assembly, target architecture, hypothesis generation, synthesis and dedup, sequencing.
- Playbooks that improve from their own run history, proven against a held-out corpus, merged by a person.
Elsewhere in the console this month
- 24 SepBlueprint status lifecycle: Draft to Completed pills, a tracker and plan progress; bookmarks retired.
- 24 SepBlueprint diagrams read relationship subtypes from the component library and draw edge labels above grouped edges.
- 23 SepBlueprints: multi-select with bulk delete and add-to-plan, plus a Creator column.
- 22 SepStacks show what a component does, not only what it is.
- 21 SepWorkspace Context: the Sources list pages, and a failed indexing run no longer strands a document.
- 18 SepBlueprint comments, reactions and share-scope changes are recorded, and Archie answers can be rated.
- 16 SepStacks render faster: inventory reads moved onto the summary rollup and the canvas layout was cut down.
- 15 SepProcesses: cost report runs are rendered by name; workspace access lists name their principals.
- 11 SepAttach files to an Archie chat.
- 08 SepPlans link to the source files they were generated from.
Want to see it on your own system? Book a demo