Overview

Syntur is building an end-to-end AI business automation platform, and Varra is its flagship. The architecture below is how a piece of business work is meant to travel through it.

Varra itself is built around a simple idea: different problems require different kinds of intelligence. Most questions need broad reasoning and nothing else. Some need a specialist. A few need to be checked before anyone acts on them. One system should be able to tell which is which. The point of telling them apart is not a better reply — it is work that comes back finished enough to act on.

One system, three demands

Three things are being asked of the same product at once, and most AI products answer one of them well. This is the claim the layers below are an expansion of; it was the home page's second section until the home page was cut back to one product story.

• Broad enough for everyday work. Most of what anyone needs from an AI is not specialised — writing, research, reasoning, analysis, coding, documents, planning, ordinary questions. Varra's default is a generalist, and it is where every conversation starts.
• Deep enough for specialized work. When general reasoning is not enough, Varra reaches for a specialist Skill — the domain's failure modes, the figures that have to be checked rather than recalled, and where an answer has to stop. Sixteen work modes are live today; six routed Skill packs are built and staged behind a switch.
• Reliable enough to act on. Confidence is not proof. Where a value can be checked against a published or authoritative source, the check wins and the answer says where it came from. Where it cannot, Varra says that too — and an account can add its own verified values for it to defer to instead. What is actually verified is published in full, and it is a short list.

Varra is the product. Syntur is the company that builds it, and Lucentra — heads-up glasses for everyday and hands-free use — is a surface for the same intelligence rather than a second product. Reference-design sourcing is in progress; it is not shipping, and there is no hardware to buy.

The shape of it

Nine layers, in the order a request meets them. Each one below says what it does, what exists today, and what is still architecture — because the difference between those is the only part of an AI roadmap worth reading.

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. Varra Runtime — the execution layer
9. Outcomes and learning

01 — Generalist core Live

The default, not the fallback. Broad reasoning: writing, research, analysis, coding, documents, planning, and questions that do not belong to any domain. Every conversation starts here, and most of them never leave.

The core has a temperament rather than a persona. It sizes a response to the question — a full explanation when one is called for, a single clean sentence when it is not. It does not perform helpfulness with forced enthusiasm, and it does not stack hedging on top of a fact it actually knows. It states what it is sure of plainly and states uncertainty as one direct clause, not an apologetic pile-up of caveats.

What is live: real-time streaming, image and PDF input, a selectable effort level for speed against depth, and an optional working memory the model manages itself — deciding what is worth writing down across a session rather than replaying everything every turn.

02 — Router Built, staged

The layer that decides what a task actually requires. Its job is to make depth automatic: you describe the work, not the tool.

What it determines, in the design: intent, which Skills apply, which tools are needed, how much risk the answer carries, which model to use, and how much verification the output has to survive.

Be careful with the status here. The router is built and tested, with deterministic rules first and a model classifier only where the rules are inconclusive. It carries its own eval set and its own telemetry, and every failure path — a timeout, invalid output, a telemetry error — fails open to the ordinary response path rather than blocking an answer. It runs behind a three-position switch that is off by default, with a shadow position that routes and records without applying anything. Nobody using Varra today is being routed. Model selection and risk scoring are design, not code.

03 — Work Items Live, nothing automatic

The object that turns a conversation into a tracked piece of work. A Work Item is an account-owned record of something that has to get done or resolved: what it is, what state it is in, which conversation it came from, and what was concluded about it in the end. It is the difference between a system that produces replies and one that can be asked what is still open.

It is deliberately narrow. A Work Item is not conversation history, not a verified finding, not an approval, and not an action — and resolved means somebody marked it resolved, not that anything was verified, approved or executed. Four states only: open, blocked, resolved, cancelled. Saving is explicit, no transcript is copied automatically, and the record is exported and erased with the account like everything else.

Be careful with the status here. The storage, the versioned edit rules and the API exist in the engine, along with an outcome record that can be attached to a Work Item afterwards — achieved, partly achieved, not achieved, or indeterminate. All of it is reachable now: the product carries a Work Items view, a New Work Item control and a form for recording an outcome, so one can be created, tracked, updated and closed by hand. What is still missing is everything automatic — nothing creates a Work Item on its own, and no routing, verification or execution reads one. It is the groundwork for carrying work across steps, and what you can use today is the carrying, not the automation. Where it is going →

04 — Specialist Skills Staged Modes live

A Skill is a body of domain instruction loaded for one request when a general answer is not good enough: the domain's failure modes, the figures that have to be checked rather than recalled, what a competent answer contains, and where it must stop.

Six Skill packs exist in the routing registry — construction invoice audit, document evidence analysis, electrical troubleshooting, HVAC diagnostics, financial analysis and investment research — and they declare which other packs they can run alongside, because a disputed invoice is a document question and a finance question at once. They are staged behind the same switch as the router.

Separately and actually live: sixteen work modes you can select yourself, each replacing the working context for the conversation. That is the current way to get depth, and it is the thing the router is meant to eventually make unnecessary. The full catalogue and each entry's status →

05 — Company context Planned

A capable model can explain what a pay application is. It cannot know your accounting codes, your approval thresholds, which vendor always omits the PO number, or that “the Harbor job” is project 2291. That is not general intelligence — it is a specific company, and it is most of what separates a correct answer from a usable one.

The intent is a company operating layer: documents, policies, systems, workflows, vendors, terminology, historical context and permissions, held above one shared core and consulted only for that company's work. The alternative — a separately trained model per customer — is expensive, slow to update, impossible to audit, and puts one company's data somewhere another company's might reach.

The narrow case is live, and it is the one part of this layer you can use today: an account's own checked values sit alongside the built-in tables, your value takes precedence over the general one, and an answer that used it is stamped as coming from your account rather than from the built-in reference. Entries are stored per account and per mode, managed from a panel in the account menu, and keyed by the same canonical lookup the built-in tables use — so “12 AWG copper” fires on the same questions “12 awg” does, rather than creating a row that silently never matches. That is company-specific knowledge changing a company's answers, in production, at exactly one kind of fact. Everything else on this layer — documents, policies, systems, terminology, approvals — is architecture. What this looks like for a business →

06 — Tools Partly live

Reasoning stops being enough the moment an answer depends on something the model does not contain. Tools are how Varra reaches it.

• Web search — live. Used when a question actually depends on current, real-world information; not on every query by default, and not never.
• Documents — live. A PDF or an image can be handed to Varra directly and reasoned over.
• Working memory — live. Varra keeps its own notes across a session, deciding for itself what is worth recording.
• Web fetch, code execution, and a stronger advisor model — built, not switched on. All three are wired into the engine and none is enabled in the deployed product today.
• Connected business systems — planned. Email, document storage, project management, accounting and ERP, APIs, business databases, communication platforms. None of these is connected today. Where you see one named on this site, it is a direction, not an integration.

07 — Varra Assurance Limited live coverage

Varra does not treat confidence as proof. Where a value can be checked against evidence, a rule, a calculation, a source document or a published reference, the check is what wins and the answer carries where it came from.

Today that means one mechanism, working end to end and narrow: the engine asks for the exact figure an answer turns on in a structured field, and where a verified table covers that figure, the table's entry replaces what the model wrote. Three of the sixteen modes carry such a table and two of those are published in full.

What that honestly implies: most Varra answers today are not independently verified. They are the model's own reasoning, and Varra says so rather than dressing them up. Widening what can be checked before an answer leaves is the work, not a claim already banked. The published tables, the method and the limits →

08 — Varra Runtime Planned

Varra Runtime is the execution layer being designed behind Varra: secure access to connected services, browser environments, isolated code environments, and eventually full computer-use environments. Its purpose is one thing — to move Varra from answering work to completing approved work.

Where it sits, and what it is not

Runtime is a separate execution layer, not part of the Router. Keeping those apart is the whole point of the design, because they answer different questions:

Worked through one case: the system needed is a legacy ERP; the tool is access to that ERP; the runtime method is desktop, because the ERP has no usable API; verification is required because the action writes a financial record; and the execution is submitting the invoice. Collapsing those five into “the agent does it” is exactly how a system ends up acting when it should have stopped.

Four execution environments

Runtime is being designed around four ways of reaching a system, chosen by what that system actually offers. The preference order matters: a direct API where one exists, and browser or computer execution only where no reliable API does. An API call is inspectable, repeatable and cheap; driving a screen is none of those, and is the fallback rather than the ambition.

The path a request takes

Runtime is only reached at the end, and only through a gate:

1. Request
2. Generalist core
3. Router
4. Work Item
5. Skills · Company context · Tools
6. Risk + verification
7. Execution gateway
8. Varra Runtime
9. Connectors · Browser · Sandbox · Desktop
10. Action
11. Outcome

The two shaded steps are the ones that make the rest safe to build. Runtime does not act because a model is confident; it acts because a gate ahead of it said the action was permitted, evidenced and within policy.

How execution is staged

Even once Runtime exists, the intent is not to hand it 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.

What is actually built

None of Varra Runtime exists today. There is no runtime service, no execution gateway, no connector to any external system, no browser or desktop automation, and no sandbox of Syntur's own. Varra holds no credentials to anything, writes to no external system, and submits nothing on anyone's behalf. Everything in this section is design.

Two pieces of groundwork are real, and they are worth naming precisely because they are small. The router already checks whether a Skill's declared capability requirements are available in the environment and refuses to route when they are not — that is the mechanism a runtime capability would eventually attach to, and today no Skill declares a requirement and nothing populates the available set, so the check never fires. And the router's decision record carries risk_status and verification_status fields that are the gate's natural home; both are hard-coded to not_evaluated and nothing anywhere assigns them. The shape is there. The gate is not.

Long term Runtime could serve more than Varra's web surface — Lucentra and other Syntur products would need the same secure place to act. It is architecture, not a product being sold, and there is no external developer access to it.

09 — Outcomes and learning Planned

An approval that gets overridden, a figure a person corrects, a verification that fails — each is information about how work actually goes in a particular company. The intent is for those outcomes to improve routing and company-specific behaviour over time.

One piece of groundwork is real, and it is small: an outcome can be recorded against a Work Item — achieved, partly achieved, not achieved or indeterminate — appended as history rather than edited over, and the product carries a form for writing one. Nothing reads it back. No routing decision, no model and no behaviour anywhere changes because of it. Recording an outcome is the first step; learning from one is the layer, and that is not built.

What this is not: a model quietly retraining itself on your documents. The design is structured, governed and scoped to the company the outcome came from — inspectable and reversible rather than baked into weights. It is last on the list because getting it wrong is worse than not having it.

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. That is a deliberate choice rather than a detail: the alternative is training a model from scratch, which for a company this size means a worse model and a slower one. The layers above — routing, Skills, company context, verification, the surfaces it runs on — are where the product actually lives.

Generating a reply means sending your message and the earlier turns of that conversation to Anthropic's API. That is described in the privacy policy.

What stops someone else doing this

It is the fair question to ask of anything built on a model it does not own, so here is the honest answer: the model is not the hard part, and it is not what is being defended.

Anyone can call the same API. What is harder to copy in an afternoon is the layer that decides when the model is not allowed to answer on its own, and the checked values it defers to when that happens. A torque figure, a breaker rating for a given wire gauge, a nominal lumber dimension: each has a right answer, and each has to be gathered, verified and kept current by someone willing to do unglamorous work. That reference data compounds — every domain filled in makes the next integration worth more, and none of it arrives by prompting harder.

The second thing is the company layer. A general assistant that has never seen your vendors, your codes or your approval rules is starting from zero on every task that matters operationally, and that gap does not close with a better base model.

Neither is a permanent moat, and it would be dishonest to call them one. They are a head start on work that has to be done by hand, in places where being wrong is expensive enough that people notice.

Where the commercial focus sits

The product direction is general-purpose. The commercial focus deliberately is not: it is small businesses and operational teams, with the deepest early advantage in construction and technical work. That is where the existing domain understanding actually is — construction, field work, finance operations, invoices, project workflows, compliance, electrical, HVAC — and it is where the difference between a plausible answer and a checked one is a cost somebody absorbs.

Try Varra now →