Advanced Workflows

What it does#

A classic workflow is an ordered list of steps a person authored, and it runs the same way every time. An advanced workflow is a mission: a brief that says what to localize and to what quality bar, a fail-closed list of the tools it is allowed to use, a roster of models, a budget in money and tokens, and a set of fences. The system owns a run inside those fences and writes down everything it did. You read the classic workflow; you read the advanced transcript.

The two tiers live side by side. The classic step-list engine remains the default for repeatable, human-authored pipelines; the advanced tier is for ambiguity, visual context, and judgment calls. Nothing migrates between them, and turning the advanced tier on never changes how the classic engine behaves. The whole tier is off until an operator opts in from the settings, and every one of its surfaces stays hidden until then.

Every capability is available on the web, the API, the command line, and the MCP server in the same release, because the harness is itself a tool that agents drive.

How a mission runs#

A mission runs in one of two modes over one shared loop. A scripted mission follows a fixed sequence of tool requests with no model in the loop, which is how the rails are proven. A conductor mission puts a planning model in charge: it proposes a plan, every step of that plan is validated before anything runs, and a malformed plan is rejected outright, so the system never executes a guessed action. The model only ever requests a tool from the mission's allowlist; a dispatcher runs it, and re-checks the run's organization and customer boundary, budget, and fences on every call. A tool not on the allowlist simply does not exist to the run.

The flagship shape is the vision-and-text committee for a string that carries a screenshot. A vision delegate reads the image into a structured description of context, not a translation. One or two text delegates then translate with that context, the approved terminology, translation memory, and learned memory folded into a task card. When candidates disagree, a single-round adjudicator either picks one candidate exactly as written or produces a minimal merge, and records its reason. The canonical case: the string "Book" beside a flight-checkout screenshot resolves to the booking sense, with a rationale that cites the image, and the publication sense loses with the reason recorded.

A text delegate can be marked context-blind: it is sent the source text and the target locale only, with no image description, glossary, translation memory, or learned memory. Its candidate is an independent reading of the bare string, which is what produces a genuine disagreement for the adjudicator to resolve. Blindness shapes only that candidate; the adjudicator still weighs all the evidence, and it is told which candidate was blind. A roster whose text delegates are all context-blind is refused, so a mission can never ship a context-free translation by construction. The adjudicator should be a different model family from the candidates, and every decision records how independent the judge was, in three honest states: separated, self-preference, or unknown when a family cannot be resolved.

Documents and keys#

A conductor run delivers into a real project through the same sanctioned write path the classic flow uses, so translation-memory locks and the refusal and quarantine perimeter apply exactly as they would on any other machine write. A key project's winning targets land on its string-key values. A document project is handled two ways. A segmented document is expanded into one committee unit per segment, each delivered exactly as written. A full-text document is decomposed into one unit per paragraph, translated a paragraph at a time, reassembled in order, and written once.

A document has no screenshot, so the committee's disagreement comes from the context-blind text delegate rather than a vision delegate; the recommended document committee is one sighted delegate, one context-blind delegate, and an adjudicator, with neighbouring source as the sighted delegate's context.

Full-text delivery is fail-closed. A held or missing paragraph, a paragraph-count mismatch, damaged inline formatting tokens, or a quality verdict that cannot be read on any paragraph holds the whole document: its body stays unwritten, and the run still completes with the other documents delivered. Each document ends in one of four outcomes, reported on the run's delivery summary: delivered, flagged (written, with a review flag raised), held (a paragraph could not pass, so nothing was written), or refused (a translation was withheld, so nothing was written). This is a deliberate asymmetry worth knowing: where the classic tier flags damaged inline tags and ships, the advanced full-text path holds the document instead.

Verification rules#

A mission can carry a small, bounded set of short verification rules: plain constraint lines a correct translation must satisfy, such as keeping a product name untranslated or holding a formal register. Each rule is placed as a fenced constraint into every committee translation and adjudication prompt, including the context-blind delegate, because a rule is a constraint, not context. Rules are data, never instructions: a rule that happens to read like a command is just a numbered line inside the fence. The number of rules and the length of each are bounded, and a request past the bound is refused on every surface.

Enforcement happens at the delivery gate. When a quality lens gates the mission, a fail-closed verifier judges each unit against every rule; a breach, or a verdict it cannot read, holds that unit with a rule-violation reason and the rule text as the note. A rule breach holds a unit even under an advisory lens whose own findings never block, so attaching a rule to an advisory mission turns a breach into a hard hold. On a mission with no lens attached, rules still shape the translation and adjudication prompts, but nothing is held. The one exception is an operator-approved empty delivery whose unit target is itself blank: a human decision to ship empty is not silently reversed by a re-hold. A non-blank unit always runs the rules check, so a real translation is always verified. The rules in force are recorded in the run's plan record and shown on the mission, so an operator can see exactly what the committee was held to.

The Evaluations Lab can measure a translation setup against a gold set of these rules and, as one of its arms, run the advanced committee itself against them. See Evaluations for the rules verifier and how a blank candidate is handled.

The research arm#

Cost, fences, and recovery#

An upfront estimate. A conductor mission carries a plan estimate of cost, tokens, provider calls, and units that forecasts the whole committee spend, not just the planning call: the plan, a vision read per imaged unit, every text delegate, the adjudicator, and the per-unit judge when a lens is attached. It is a forecast, not a cap, priced through the same table the spend ledger uses, and shown on every surface.

Live guardrails. The dispatcher, not the prompt, holds the budget: a per-run ceiling in money and tokens, a maximum number of tool calls, a cap on provider calls per unit, and a wall-clock limit. Each spend is authorized before it runs, so a tiny ceiling stops a run even against the offline mock engine. A budget or fence you request above the install ceiling is capped, and the response names each capped fence rather than silently changing it. A unit that exceeds its per-unit call fence is skipped and recorded; the units that finished still deliver.

Honest failures and recovery. A run is synchronous and stops the instant a fence trips or the budget is hit, always keeping the partial transcript. Stopping on money is a distinct, honest status from stopping on a break. When a run trips the wall-clock limit it still delivers the units that finished and passed their check, and marks every unit it never reached, so a timed-out run's remaining work is distinguishable from work that was never attempted. A run whose process dies mid-loop is recovered by a background sweep that marks it failed and abandons its staged targets so they can never deliver; a live run is never touched.

Parallel dispatch across engine hosts. A mission can dispatch a unit's independent committee calls concurrently when they resolve to distinct engine hosts, for example two local model servers running the same model. Calls that share a host stay sequential, because a single local box serves one request at a time; the vision read stays before the fan-out, and the adjudicator and judge stay after it. Spend is identical to a sequential run, only wall time drops, and the transcript is stored in a fixed order so a later replay stays stable. A single-host mission runs exactly as before.

The transcript and erasure#

Every run writes a durable, auditable transcript: the plan, every tool call and its result, every delegate candidate, every adjudication with its reason, and the final delivery record, in order. When someone asks why the agent chose a translation, the answer is a row you can read. Each entry renders as one plain-English summary line, with the raw detail one click away on the web run page and behind a flag on the command line, and the web and command-line surfaces print that line from the same summarizer, so neither can describe an entry differently than the other.

The run view folds the transcript into per-unit cards: each unit's candidates with their engine and whether each was sighted or context-blind, the adjudicated winner and its reason, the quality verdict with its spans, any web-search evidence, and a status with a plain reason when a unit was held. Every staged target records whether its screenshot was actually read, in one wording used everywhere, so "we did not look" never reads like "there was nothing to see": read, no screenshot, screenshot unavailable, or not applicable for a unit that has no image path at all, such as a document paragraph.

The system can keep a full record of the exact request and reply for every model call, off by default and readable only by an administrator on the host. Its bodies-withheld summary, which reports call counts, statuses, error classes, finish reasons, spend, and timings but never the prompt or reply text, is readable with a docs-scoped key over the API, the command line's remote mode, and the MCP server, scoped to your own organization.

Erasure reaches the harness. When a document is erased, whether by a scheduled retention sweep, an administrator deleting it, or a data-subject erasure request, every advanced-tier carrier of that document's content goes with it: the quality findings that quote it, the staged candidates' source and target text, the transcript's content entries, and the mission roster's stored previews. Each count is named in the erasure record. The run row itself, its counts and its delivery record survive, because erasing a document is not the same as deleting a run, and a run that also translated other documents keeps their content untouched.

Getting started#

Turn the tier on from Settings, then start from a named template: a template prefills a mission's mode, tool allowlist, committee roster, research toggle, and fences, and it is a suggestion, never a bypass, so applying one still runs through the same validation as building a mission by hand. The create form's target-locale picker lists a project's active locales and refuses one that is not active before the mission is created, which is what catches the common mix-up between a regional and a broad Spanish locale.

1. Enable Advanced Workflows in Settings, then open the Advanced page.
2. Start from a template, or create a mission bound to a project: pick a mode, the tools, the committee roster, a budget and fences, and a target locale.
3. Run the mission and open the run view to read the transcript, the per-unit cards, and the delivery record.

advanced templates list
advanced create --project 7 --name "Checkout committee" --mode conductor \
  --tools tm.lookup,glossary.plan,provider.translate,provider.judge,quality.judge,deliver \
  --text-engines local,local --context-blind-engine pos:2 \
  --adjudicator-engine claude --units '[{"unit_key":"btn.book"}]'
advanced run 2
advanced transcript 2
advanced show 2 --cards

Every mission verb that has a matching server route also works against a running server in remote mode, scoped by your API token, so the tier can be driven headlessly from CI. See the CLI reference for the exact list.

Works with#

• Workflows: the classic step-list engine is the other tier, the default for repeatable pipelines; the advanced tier sits beside it and never touches it.
• TM, Glossary, and Memories: a mission's read tools gather translation-memory precedent, resolve the project's approved terminology, and pull learned memory into a translation, scoped to the run's project.
• Keys and Documents: a run delivers into a key project's string values, a segmented document's segments, or a full-text document's body, always through the sanctioned write path.
• Engines: every delegate, vision read, and judge resolves an engine and bills through the spend ledger and the run budget; with no key the offline mock answers deterministically, so the whole flow runs at zero cost.
• Evaluations: the Lab can run the advanced committee as one arm of a rules-based meta-evaluation, keeping the mission and run rows it produces as the spend audit trail.
• AI agents and MCP: the tier is driven from the API, the command line, and a set of MCP tools in the same release as the web surface.

Current limits#