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.

1. Generalist core
2. Router
3. Work Items — the unit of work
4. Specialist Skills
5. Company context
6. Tools
7. Varra Assurance — verification
8. Runtime and execution
9. 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, the two mechanisms, and coverage →

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 and the Advisor model — built in the engine. Neither is available in the current Varra product interface.
• 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.

---

What it runs on

The third-party AI model provider referred to in the privacy policy is Anthropic. 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. Generating a reply means sending your message and the earlier turns of that conversation to Anthropic’s API, as the privacy policy describes.

What Syntur builds

Anyone can call the same model. What Syntur builds is the part around it: the layer that decides when the model is not allowed to answer on its own and the checked values it defers to, the records that let work be tracked rather than only answered, and the infrastructure that keeps checks, approvals and actions separate. None of that is a permanent advantage, and it is not described as one here.

---

Try Varra now →