Infrastructure
Varra is the engine people use. Underneath it, Syntur is building the infrastructure that lets business work be recorded, checked, approved and — within narrow, explicit bounds — carried out. Most of it is foundation, not product.
Every component below carries two labels, because they answer different questions. Maturity says how far it is built: a built foundation, something still being built, or a future direction. Availability says who can reach it: public in Varra, reachable only through the engine’s API with no product interface, internal, or switched off. A component can be built and still be available to nobody. The authoritative, dated record is build status.
Distinctions this infrastructure is built to keep
- A router decision is not permission.
- An Assurance result is not approval.
- A Work Item marked resolved is not a verified business outcome.
- Implementation does not mean public availability.
- Execution capability does not mean authorisation.
- Evaluation does not mean model improvement.
How the pieces relate
There is no automatic pipeline. Where the engine connects these pieces, each step is a separate, explicit request from the signed-in owner, and each one re-checks the facts it depends on: a Work Item can have a run admitted against it; that run gets an Assurance verdict; Runtime can advance it one record-only step and pause; the owner can be asked to approve one exact action; and Relay can make one attempt at that action. Nothing advances on its own, and none of this path is in the product today.
Components
01 — Varra engine
Maturity Built
Availability Public
The part people use today: conversation, reasoning over documents and images, web search where a question depends on current information, and a working memory the model keeps across a session. It runs on Anthropic’s Claude models through their API. Syntur does not own or operate a general-purpose foundation model of its own, and nothing on this site should be read as saying otherwise. Varra →
02 — Router and Skills
Maturity Limited foundation Orchestration building
Availability Modes public Routing default off
Sixteen work modes are public and you choose them yourself. Separately, a router is built and tested with its own eval set. It supports off, shadow and active modes: shadow routes and records a decision without applying any Skill, and active may apply only approved Skills. The source default is off; current production configuration is not asserted on this page. Eight Skill descriptors are registered and enabled in the routing registry, and three are currently approved for application when Router mode is active. Broader orchestration — several capabilities contributing to one piece of work — is still being built. A routing decision says what a task appears to need. It is not permission to do anything. Skills →
03 — Work Items and outcomes
Maturity Built foundation
Availability Public, by hand
The durable record of a piece of work: an account-owned item with a title, a description, one of four states — open, blocked, resolved, cancelled — versioned edits, and an outcome assessment that can be appended afterwards. Varra carries a Work Items view, so an item can be created, tracked and closed by hand. Nothing creates one automatically. A Work Item marked resolved means a person marked it resolved; it is not a verified business result, and an outcome assessment is a record, not a measurement.
04 — Agents and durable runs
Maturity Run-state foundation Product agents building
Availability API only Not in Varra
The foundation an agent needs before it can be trusted with more than one step: an Agent Run bound to one exact Work Item revision, with its own steps, attempts, a bounded lease, a budget, a deadline, cancellation, and records that survive a restart. It exists in the engine behind authenticated API routes and has no interface in the product. There is no general autonomous or background agent: nothing starts a run on its own, and nothing runs while nobody is asking.
05 — Runtime
Maturity Bounded foundation Environments building / future
Availability API only Not in Varra
The control plane that moves a run forward. What exists is deliberately narrow: one record-only progression that requires a current, passing Assurance verdict, records a single internal step, and then pauses the run. It performs no external action, and a paused run does not mean the work, or the objective behind it, is complete.
06 — Relay
Maturity Narrow groundwork
Availability API only Not a public product
Relay is where an approved action leaves Syntur’s systems. Today it does one thing: it takes one exact, current owner approval and makes one attempt to send one plain-text email through a Gmail connection the owner authorised separately from signing in. One recipient, no attachments, and an attempt that is never automatically retried. Relay has completed a production founder proof: an explicitly approved plain-text Gmail send received provider acknowledgement and independently verified inbox delivery. Gmail authorisation is working in production, and the proof covers this one approved send path on the founder’s own account. Relay has no interface in Varra, is not generally available, and is not offered as a standalone execution platform. Broader public access is being built. Being able to send is not the same as being authorised to: Relay acts only on an approval, never on its own judgement.
07 — Assurance
Maturity Limited deterministic checks Coverage building
Availability Reference checks public Run checks API only
Two mechanisms, both narrow. In the product, a verified reference table can replace the model’s own figure, and the answer says where it came from — nine published rows across two tables. In the engine, a deterministic evaluator checks declared conditions against supplied evidence and records a verdict that the run path above requires. Neither is a general truth guarantee. An Assurance result says a stated check passed; it is not approval, and it never grants permission. Mechanism, coverage and limits →
08 — Permissions and approvals
Maturity Exact-action foundation Organisational permissions future
Availability API only
An owner can approve or reject one immutable proposed action — its target, its content and its expiry fixed before anyone decides — bound to the run and the Assurance verdict it came from. An approval covers that one action and nothing else. Team roles, delegated authority and organisation-wide policy are not built.
09 — Telemetry
Maturity Scoped records
Availability Internal
Records kept for specific jobs: routing decisions for evaluating the router, spend and usage accounting that survives a restart, and the history of each run and attempt. This is not a customer observability product, and it does not measure whether a business outcome was achieved.
10 — Evaluation
Maturity Internal offline tooling
Availability Internal
Eval sets and harnesses for the router, run offline and in continuous integration. There is no public evaluation service, no benchmark result being claimed, and no automatic loop that turns an evaluation into a better model. Evaluation tells the team where something stands; it does not by itself improve anything. Research →
Build status
This page summarises. Build status is the authoritative, dated record of what is implemented, enabled, public, internal, partial, building and future — and it is a record of capability, not a measure of uptime.