For business

Syntur is building an end-to-end AI business automation platform — a system a business hands work to, not just prompts. Varra is the flagship, and it is live today for the reasoning, document and verification work described below. The layers that would carry an approved task into the systems your company already runs on are what we are building next.

Talk to Syntur →

What we are building

The destination is easy to state and hard to build. A business describes an objective — reconcile this month’s subcontractor billing, get this permit package ready, work out why this invoice does not match the purchase order. Varra determines what that actually requires, brings in the specialist knowledge and the company’s own information, does the work, checks the parts that carry a cost, puts the decision in front of a person where the decision is theirs, and — once the execution layer exists — carries the approved result into the systems the business already runs on and confirms it landed.

Most AI products stop after the first two steps. For an operating business the value is in the rest: work prepared, checked, approved, finished, and recorded. That is the platform, and every layer described on this page exists in service of it.

How the platform is intended to work

One pass, from a business objective to a recorded outcome. This is the architecture rather than a feature list, so each stage carries the status it is actually at — the front of the sequence runs today and the back of it is being built.

1. LiveBusiness objective. You describe the work in your own words, with whatever you have — documents, photographs, figures, a thread nobody has untangled.
2. StagedRouting. Varra works out what the task requires rather than asking you to pick a tool. Built and tested; switched off today, so you still choose the mode yourself.
3. Partly livePlanning, and the piece of work itself. One tracked item carrying its state and its history, so a job can be picked back up rather than restarted. You create and update it yourself; nothing creates one for you yet.
4. Partly liveSpecialist skills and agents. Sixteen domain modes are live and you select them. Six routed Skill packs are built and staged behind the same switch as routing. Several packs contributing to one task is design.
5. Partly liveBusiness information and tools. Documents and images you hand over are read today, and web search runs where a question depends on it. Reading directly from your accounting, project or email systems needs connectors, which are not built.
6. LiveReasoning. Comparing sources, finding what does not match, naming what is missing, and preparing the draft, summary or document that comes next.
7. Partly liveVarra Assurance — evidence and verification. Where a verified reference covers the figure, the reference replaces the model’s answer and the reply says where it came from. Checking a value against your own contract or budget needs the company layer.
8. PlannedRisk, permission and human approval. Whether the action is allowed, what it would cost to get wrong, and whether a person has to sign it off before anything moves.
9. PlannedExecution in your systems. Varra Runtime: a connector where a system offers an API, a browser session where it offers only a login, a sandbox for computation, a desktop environment where the software leaves no other way in.
10. PlannedConfirmation, reconciliation and recorded outcome. Whether the action actually succeeded, what a person changed, and what that should teach the next one. The outcome record exists in the engine; nothing reads it yet.

What Varra does for a business today

A contractor, a trade business, or a field service or technical operation — the kind of company where a wrong figure costs real money and a general-purpose chatbot has no way to know your job, your vendor, or your local code amendment. That is the wedge; the intelligence underneath is general-purpose and not limited to it. What works now, in a browser, free:

• LiveAnswer a technical question against a trusted reference. Wire gauge, lumber sizing, and the other published tables override the model's own guess where they apply.
• LivePull the useful parts out of a document. Hand it a permit set, spec sheet, or estimate and get the dates, scope, and line items back.
• LiveCompare documents and find what does not match. Two versions, a quote against an invoice, a submittal against a spec — where they disagree, and what support is missing.
• LiveGive Varra your company's own checked values. A “Your reference data” panel in the account menu takes figures you have verified against your own equipment, suppliers or local code amendments. Yours beat the built-in table, which beats whatever the model remembered, and an answer that used yours is stamped as coming from your account. This is company-specific knowledge changing a company's answers, in production, today.
• Partly liveReview an invoice or business document for issues. Amounts, vendor, and line items are extracted today; checking them against a contract, PO, or budget needs the company layer below.

What is being built

Named by the capability rather than the internal project, and ordered by dependency. The roadmap carries the longer version and the status page the exact position of each.

• BuildingThe company operating layer. Your documents, policies, systems, vendors, project structures, terminology and approval rules, held above one shared core and consulted only for your company's work.
• BuildingConnectors. Email, document storage, project management, accounting and ERP — a direct API wherever one exists, because an API call is inspectable, repeatable and cheap to verify.
• BuildingWork tracking and agent orchestration. A piece of work that survives the conversation it started in, and several specialist packs contributing to one task rather than whichever matched first.
• BuildingRisk, permission and approval controls. What a given account may do, what has to be verified before it does it, and which decisions are always a person's.
• BuildingExecution infrastructure. Varra Runtime, in four forms, reached only through the gate above.
• BuildingTelemetry and outcomes. What was approved, what was corrected, and what that should change about how the next one is handled.

The current boundary

Stated once, in one place, so the rest of this page can describe what is being built without hedging every sentence. As of today:

• Varra does not act in any external system. It holds no credentials to one, writes to none, and submits nothing on anyone's behalf. Signing in with Google uses an identity-only scope and reads no mail and no files.
• There is no company workspace. You cannot upload your policies, connect your accounting system, or set an approval rule. The one exception is the per-account reference data above, which is live.
• Nothing runs unattended. Varra works on what you hand it in a conversation. It does not watch a mailbox, monitor a system, or start work on its own.
• Nothing is automated end to end. The stages marked Staged or Planned are the platform being built, not capabilities being sold, and every mark on this page is there so the two are never confused.
• Business billing is not switched on. Varra is free to use today, and the Business tier is described rather than sold.

None of that is a reason not to talk to us. It is the reason the conversation is worth having now, while the workflows being built are still being chosen. The full layer-by-layer status →

The problem with a general model on specific work

A capable model can explain what a pay application is. It cannot know that your company codes retainage to a particular account, that this vendor's invoices always arrive missing the PO number, that anything over fifteen thousand dollars needs a second signature, or that “the Harbor job” and project 2291 are the same thing. That knowledge is not general intelligence. It is your company, and it is most of what makes an answer usable rather than merely correct.

Every company differs on the same short list: invoices, vendors, project structures, accounting codes, approval rules, internal terminology, policies, documents, systems, and the way work actually moves between people. None of it is in a model's training data, and none of it should be.

One core, a layer per company

The answer is not a separately trained model per customer. That is expensive, slow to update, impossible to audit, and it puts one company's data inside a thing another company might touch. Varra's direction is a company operating layer: a bounded, inspectable body of context that sits above one shared core and is consulted for that company's work only.

The core stays one system, so every improvement to reasoning, to a Skill, or to verification reaches every customer at once. The company layer stays separate, so what your business knows is scoped to your business and can be read, corrected, and revoked rather than baked irreversibly into weights.

A worked example: work in the field, paperwork in the office

This is the shape of the problem, in the industry where we understand it best. A crew does the work; the record of it arrives as photographs, scribbled hours, a delivery ticket, a receipt and a thread of texts; and somebody in an office turns that into something a customer will pay against. Each step is marked with what it would actually take, so the shape is clear without implying any of it runs unattended.

1. LiveYou hand over what the job produced. Photos, hours, a delivery ticket, a receipt, notes — however they turned up. Varra gathers none of this itself; you give it to Varra in a conversation, and that part works today.
2. LiveVarra reads what you gave it. Dates, quantities, amounts, vendors and line items come back out of the documents and photos.
3. Partly liveWhat is missing gets named. Varra can say what is absent from the material in front of it. It cannot yet know what your company requires before a ticket counts as complete — that needs the company layer.
4. PlannedValues are checked against your own records. The contract, the schedule of values, the PO, the rate sheet. Requires the company layer and a connection to wherever those live.
5. PlannedA package is prepared. T&M or T&E documentation, a change-order draft, COR support, a labor/material/equipment summary, or the evidence behind a billing adjustment. None of these exist in the product today.
6. PlannedA manager reviews it. The review step is the product, not a safeguard bolted onto it. Nothing is meant to leave on Varra's own judgment.
7. PlannedApproved work moves into the system you already use. Requires Varra Runtime. Varra holds no credentials to any external system and writes to none.

Two of those seven steps work today and one works in part — the marks say which. The rest is the platform being built, on the terms set out under the current boundary above.

Varra is not another system of record

You already have one, or several, and the last thing a team of eight needs is a fourth place to type the same thing. The direction is for Varra to work around the systems a company already runs — project management, field service, accounting, ERP — reading what the business already produces and preparing what has to go into them. Not replacing them.

Varra connects to none of those systems today; the connectors that would change that are being built.

A second worked example: an invoice arrives

This is the workflow the company layer and the execution layer exist for. Each step is marked with what it would take today, so the shape of the thing is clear without implying that any of it runs unattended.

1. PlannedVarra retrieves the email. Requires a mail connector. Varra has no access to any mailbox — sign-in with Google uses an identity-only scope and reads nothing.
2. LiveExtract the invoice. Hand Varra the PDF or an image today and it reads the amounts, dates, line items, vendor and terms.
3. PlannedCheck company context. The PO, the project, the vendor record, the accounting codes, the approval thresholds. Requires the company layer and a connection to the system of record.
4. StagedApply the relevant Skills. Construction Invoice Audit and Document Evidence Analysis both exist and compose with each other — behind a switch that is off. See Skills.
5. Partly liveVerify the result. Arithmetic and internal consistency against the document you supplied can be checked now. Checking against a contract or a schedule of values needs the layer above.
6. PlannedSelect the execution method. Does this accounting system have an API, or only a login and a screen? That choice is the job of the execution gateway, and it is not built.
7. PlannedRuntime carries it out — through a connector, a browser session, a sandbox or a desktop environment, whichever the system actually supports. Varra Runtime does not exist today in any of those four forms.
8. PlannedThe action completes, or escalates. Anything outside granted permission stops and goes to a person. Varra writes to no external system today and submits nothing on anyone's behalf.
9. PlannedLog the outcome. What was approved, what was corrected, and what the correction should teach the routing next time.

Read the marks rather than the sequence: step two works today, and the rest is what the sequence is being built toward. Accounts payable running itself is not being claimed, and would not be worth claiming before the gate in front of it exists.

Why the execution method matters

Step six is the part most worth understanding, because it is where a lot of automation quietly becomes fragile. Varra's design preference is explicit:

• A direct API wherever one exists. An API call is inspectable, repeatable, permissioned and cheap to verify. It is the first choice every time.
• A browser session where there is a portal but no usable API. Plenty of the systems a small business actually runs on have a login and nothing else.
• A sandbox where the work is computation — a spreadsheet to process, a file to transform, a document to generate.
• A desktop environment only where the software leaves no other way in. Legacy accounting and ERP packages are the honest reason this exists, not an ambition to drive a screen for its own sake.

A system that can only do the first is useless against half of what a real company runs. A system that reaches for the last one first is unreliable and hard to audit. Choosing correctly, per system, is the point of having a runtime layer at all rather than a pile of scripts.

Why start here

Varra's long-term direction is general-purpose. Its commercial focus is deliberately narrower: small businesses and operational teams, with the sharpest early advantage in construction and technical work.

That is not a hedge, it is where the existing understanding is. The domain modes, the reference data, the first Skill packs and the invoice and document work all come from construction, field work, finance operations, project workflows and compliance — the areas where the difference between a plausible answer and a checked one is a real cost somebody absorbs. A team of eight running jobs, invoices and approvals out of email and a spreadsheet is a harder customer to satisfy than a general consumer, and satisfying them is what produces a system worth pointing at anything else.

Learning from outcomes

An approval that gets overridden, a figure a person corrects, a verification that fails: each of those is information about how this company actually works. The direction is for those outcomes to improve routing and company-specific behaviour over time.

What that is not: a model quietly retraining itself on your documents. The intent is structured and governed — scoped to the company it came from, inspectable, and reversible. Nothing about this is live today, and it is the part of the roadmap that will be built last on purpose, because getting it wrong is worse than not having it.

Talk to Syntur

The business layers are being built now, which is the useful moment to be in the room. If your company's work looks like the examples above, the most valuable thing you can send is what actually breaks — the document that arrives wrong every month, the rule nobody can find, the check somebody does by hand, the ticket that never got billed. Those are what the workflows get built around.

Worth saying plainly: this is a conversation about a system being built, not a deployment you can buy this quarter. If that is the wrong timing, the roadmap is the honest thing to check back against.

Useful to include: your company, your line of work, and the first piece of work you would want automated. The link below opens an email with those three lines ready to fill in.

Talk to Syntur →

Pricing for the Business tier, and what it does and does not include today, is on the pricing page.