Varra · How it works
How Varra works
The model Varra runs on, what Syntur builds around it, and the nine layers a request meets, each labeled for how far it is built.
The model, and what Syntur builds
Varra’s reasoning is built on Anthropic’s Claude models, accessed through their API. Syntur does not own or operate a general-purpose foundation model of its own. What Syntur builds is the part around it, and that is what the nine layers below describe. What it runs on, in full →
Inside Varra
Syntur is the company; Varra is its engine, not the whole of it. The systems beneath Varra — durable runs, checks, approvals, and a narrow way to act — are on Infrastructure, each labeled for how far it is built and who can reach it.
How Varra is organized
Nine layers, in the order a request meets them. Each says what it does, what exists, and what is still architecture.
- Generalist core
- Router
- Work Items — the unit of work
- Specialist Skills
- Company context
- Tools
- Varra Assurance — verification
- Runtime and execution
- Outcomes
01 — Generalist core Live
The default, not the fallback. Every conversation starts here, and most never leave. The core sizes a response to the question, states what it is sure of plainly, and states uncertainty as one direct clause rather than a pile of caveats. Live: streaming, image and PDF input, a selectable effort level, and a working memory the model manages itself within a session.
02 — Router Built, default off
The layer meant to decide what a task requires, so that you describe the work rather than pick the tool. It is built and tested: deterministic rules first, a model classifier only where the rules are inconclusive, its own eval set and telemetry, and every failure path falling back to the ordinary response. It supports three modes: off; shadow, which routes and records a decision without applying any Skill; and active, which may apply only the approved Skills. The source default is off. Current production configuration is not asserted on this page. A routing decision says what a task appears to need; it is not permission to do anything. Routing →
03 — Work Items Live, nothing automatic
The object that turns a conversation into a tracked piece of work: an account-owned record of what has to get done, what state it is in, which conversation it came from, and what was concluded about it. Four states only — open, blocked, resolved, cancelled — with versioned edits that reject a stale write, and an outcome assessment (achieved, partly achieved, not achieved, indeterminate) appended as history.
It is deliberately narrow. A Work Item is not conversation history, not a verified finding, not an approval and not an action. Resolved means somebody marked it resolved — not that anything was verified, approved or executed, and not that a business result was achieved. Varra carries a Work Items view, so an item can be created, tracked and closed by hand; nothing creates one automatically. Saving is explicit, and the record is exported and erased with the account. Work Items →
04 — Specialist Skills Modes live Packs registered
A Skill is a body of domain instruction loaded for one request when a general answer is not enough. Today depth comes from sixteen work modes you select yourself. Eight Skill descriptors are registered and enabled in the routing registry. Three are currently approved for application when Router mode is active.
What a Skill is
A Skill is a named body of domain instruction the engine can load for one request: what the domain's failure modes are, which figures have to be checked rather than recalled, what a competent answer in that field is expected to contain, and where the answer must stop. It is not a separate model and not a separate product. The same Varra identity answers either way — a Skill changes the depth and the discipline of the answer, not who is answering.
That matters for the thing most people actually do with AI, which is ask about whatever is in front of them. A question about a rebate letter, a supplier contract and a cash-flow statement should not require three tools and three logins.
Two mechanisms, honestly described
Specialist depth reaches Varra by two routes today, and they are at different stages. Both are described here as they actually are rather than merged into one claim:
- Work modes — live. Sixteen domain modes ship in the product now. You pick one, and it replaces the working context for the conversation: its own system prompt, its own cautions, and for three of them a verified reference table that overrides the model's own figure. This is what you can use this afternoon.
- Skill packs — built, staged. Eight Skill descriptors are registered and enabled in the engine's routing registry, with their own eval set. They are selected by the router rather than by you, and they can compose with one another. Three of them, Electrical Troubleshooting, HVAC Diagnostics and Construction Invoice Audit, are currently approved for application when Router mode is active; the other five are registered but not applied. The router’s source default is off, and this page does not assert its production setting.
The direction is for the second to absorb the first: you describe the work, and Varra determines what the work needs. Choosing your own mode is the current state, not the destination.
Skills compose
Real work rarely sits inside one domain. A disputed construction invoice is a document question and a finance question at once. So a Skill pack declares which other packs it can run alongside, and the registry carries those relationships rather than leaving them implied:
- Construction Invoice Audit composes with Document Evidence Analysis.
- Document Evidence Analysis composes with Financial Analysis and Investment Research.
- Financial Analysis and Investment Research compose with each other.
- Electrical Troubleshooting composes with HVAC Diagnostics.
- Operational Exception Analysis and Operational Financial Impact compose with each other, and each declares Construction Invoice Audit and Document Evidence Analysis.
That is the mechanism a single assistant needs and a folder of separate assistants cannot have. It is also worth being precise about what it is not: composition means two Skills can inform one answer to one request. It is not a workflow engine, it does not run a sequence of steps on its own, and nothing in the registry executes anything. A piece of work that spans several domains is still one conversation with a person in it.
A Skill decides how a task should be handled and what a good answer contains. It is not how Varra reaches a system, and it is not what carries out an action — that is Runtime, a separate layer whose foundations exist in the engine. Its one part in the product is sending an approved plain-text email through Gmail, for eligible accounts. Today every Skill ends in an answer.
05 — Company context Planned Account values live
A capable model can explain what a purchase order is. It cannot know your accounting codes, your approval thresholds, or which vendor always omits the PO number. The intent is a company layer — documents, policies, systems, vendors, terminology and permissions — held above one shared core and consulted only for that company’s work, rather than a separately trained model per customer.
One narrow piece is live: an account’s own checked reference values, which take precedence over the built-in tables, and an answer that used one is stamped as coming from the account. Everything else on this layer is architecture. What this is for →
06 — Tools Partly live
- Web search, documents, working memory — live.
- Web fetch — built in the engine. Web fetch is not available in the current Varra product interface.
- Advisor — built in the engine. The Advisor is not available in the current Varra product interface. Where the engine is configured to use it, the main model may consult a second model, by default Anthropic’s Claude Opus 5, on harder requests, at its own discretion. It is not a check run on every answer.
- Code execution — built in the engine. Code execution is not available in the current Varra product interface.
- Connected business systems — Gmail sending only, for eligible accounts. Storage, project management, accounting, ERP and reading email are directions, not integrations. The engine’s one connector, a Gmail connection for Relay, is used only to send approved email.
07 — Varra Assurance Limited coverage
Varra does not treat confidence as proof. In the product, the engine asks for the exact figure an answer turns on in a structured field, and where a verified table covers it, the table’s entry replaces what the model wrote. Three of the sixteen modes carry such a table. Most Varra answers today are not independently verified, and Varra says so. An Assurance result says a stated check passed; it is not approval and does not grant permission. Mechanism, coverage and limits →
08 — Runtime and execution Mostly foundations
The layer meant to move Varra from preparing work to carrying out approved work. What exists is foundation: durable agent runs, a record-only runtime step that pauses without an external effect, exact-action approvals, and Relay, which can send one approved plain-text email. The one part in the product is that email path, for eligible accounts: an email prepared from a Work Item is sent only after its owner approves it. The rest is reachable only through the engine’s API. Agent runs and runtime →
Where it sits, and what it is not
Execution is kept separate from the parts that decide and check, because they answer different questions:
Collapsing those into “the agent does it” is how a system ends up acting when it should have stopped. Being able to execute is not the same as being authorized to.
How execution is staged
Even as execution widens, the intent is not to hand over a task and look away:
- Read — take in the documents, systems and context the task involves.
- Recommend — say what should happen and why.
- Prepare — assemble the actual thing: the draft, the entry, the package.
- Execute within approved permissions — and only those.
- Escalate exceptions — anything outside what was granted stops and goes to a person.
Varra in the product does the first three for what you hand it. The fourth exists in one narrow form, for eligible accounts: sending an approved email through Gmail, one per approval. Otherwise the last two are the foundations above, not yet a product.
09 — Outcomes Recording live, learning not built
An outcome can be recorded against a Work Item and read back as history. Nothing consumes it: no routing decision, no model and no behavior changes because of it. Recording an outcome is not learning from one, and nothing here is a model retraining itself on your documents. Where this is heading is on Research.
Where to go next
- Infrastructure — the systems beneath Varra, each labeled for how far it is built.
- Build status — the dated record of what is live, staged and planned.
- Research — where this is heading.