ORQESTRA
Sign in Request a demo
What Orqestra is

A governed AI workforce, organised like a firm.

Orqestra runs 1,172 specialist agents in teams, with a chain of command, budgets and approvals. It puts every key claim through a check against its source, records the result, and keeps a sealed record of what the agents did. Point it at a hard question, an implementation, a standing piece of operations or a market to watch, and it organises the right people to do the work properly.

AnswerHard questions, partner-gradeA senior question in, a board-ready memo out, with every key claim checked and the result recorded.Followed in full below → PlanImplementations, in the vendor's orderOracle Fusion setup plans built from Oracle's own published registry.See the real plan → ProduceThe full range of professional work50 work types and multi-part packages: board packs, diligence, launch plans, risk registers.Browse the 50 → OperateStanding teams that keep runningSales ops, content, market intelligence and launch teams, on schedules or triggers.See the teams → MeasureScores, baselines and signalsAI-visibility scoring, weekly signal briefs, re-run over time to show movement.See measurement → GovernProof of every stepBudgets, approvals, a kill switch, a trust ledger and an HMAC-sealed audit chain.See the integrity layer →
Request a demo See it work ↓
Use case in focus

A partner on call

The clearest way to see the whole machine at work is to follow one senior question through it, from the first sentence to the delivered memo. Every capability above uses the same team, the same checks and the same record.

Example brief, used throughout Should we close our 30 weakest stores and put the money into online?
The journey of one question

Six stages from a sentence to a memo you can forward. Play it, or pick a stage.

Stage 1 · The ask
YouShould we close our 30 weakest stores and put the money into online?
OrqestraTwo things before I start. Does “weakest” mean four-wall profit, sales per square foot or footfall? And are any leases ending in the next 18 months?
Plan and cost shown before anything runs
Stage 2 · The team

Six specialists, called in from a bench of 1,172

  • SLStrategy leadOwns the question
  • RERetail economistFour-wall profit, halo
  • PAProperty analystLease events, exit cost
  • CRCustomer researcherCatchments
  • FLFinance leadWrite-downs, payback
  • CChallengerArgues the other side
Stage 3 · The work
Proposed
Close all 30 and move the budget online
Challenged
Online halo sales would fall on many of them
Built on
Split the estate: close where online already serves
Every action names the fact it rests on
Stage 4 · The checks
  • C-00311 stores negative at four-wall levelconfirmed
  • C-007Online reaches most of those catchmentsconfirmed
  • C-011Halo sales on the 19 exceed savingsnot fully confirmed
5 of 5 parts of the brief answeredSealed in the audit chain
Stage 5 · The answer

Close 11 now. Test the other 19 before deciding.

Treat it as two decisions, not one: bank the easy 11 at lease events, and test the 19 for two quarters before committing the online budget.

14 of 14 key claims checked · 13 confirmed, 1 flagged
Stage 6 · The receipts
Cost
Every model and tool charge tied to this brief, in pounds
Record
Every attempt, hand-off and decision, in order
Evidence
One record per fact, with its source and verdict
Read stage 1 in full ↓

Or jump to the range of work, the model comparison, a real run or the engine room.

Stage 1 · The ask

You talk to it like you'd talk to a partner

No forms and no prompt engineering. You write the question the way you would say it. Orqestra asks a question or two back, once, the way a good partner would, and never about its own machinery. Then it shows you the plan and the cost before anything runs.

YouShould we close our 30 weakest stores and put the money into online?
OrqestraTwo things before I start. What does "weakest" mean to you: four-wall profit, sales per square foot, or footfall trend? And is any of the estate on leases ending in the next 18 months?
YouFour-wall profit. About a third of them have leases ending next year.
Plan, ready for your go-ahead
  1. Size what the 30 stores actually contribute, including halo sales online
  2. Test where online already serves each catchment
  3. Price the exit: leases, staff, write-downs
  4. Challenge the case, then recommend
Estimate shown in £Runs on your own keyApprove or change
If a brief would ship before its claims could be checked, Orqestra says so here, up front.

What's built

  • Ask, the front doorOne place to start. The landing page goes straight to it.
  • Clarifying questions, onceAt most a question or two, asked once, about the problem rather than the platform.
  • A plan before any spendSteps, routing and an estimate in pounds. Typing a change under the plan reshapes it; "yes" in any phrasing approves it.
  • Honest refusalsA refused plan says why. A paused run says whose credit it is waiting on.
  • Your own keyUsage is billed to the client's own Anthropic account, not hidden in a markup.
Stage 2 · The team

The right specialists, convened for this question

Behind the conversation sits a standing bench of more than 1,100 agents, organised like a firm: leads, specialists and reviewers with a chain of command and a visible track record. For each brief, only the people the question needs are called in.

1,172 agents · drag to turn · tap a team
Running Idle Paused Needs attention Work routed Challenge
Example team for this brief

Teams are real templates in the product. The split of agents between them, and the traffic and activity feed, are simulated for illustration.

Strategy leadOwns the question and the recommendation
Retail economistFour-wall profit and halo effects
Property analystLease events and exit costs
Customer researcherCatchments and channel switching
Finance leadWrite-downs and payback
ChallengerArgues the other side, on purpose

What's built

  • AI team, org chart and network viewsThe whole bench, by role and by connection, and still quick at 1,172 agents.
  • Track records you can seeEach agent shows what it has delivered and how consistently.
  • Chain of commandWork is routed to a lead, who routes it on. Nobody freelances.
  • Skills and team templatesReady-made teams and specialist tools, including an Oracle Fusion implementation planner.
  • Custom instructions per agentEvery agent has its own role brief, instruction files, budget and permissions. Leads also carry a persona, a wake-up checklist and their own memory. Inspect one below.
Inside one agent · from the starter team

Nadia, chief of staff

Role: lead · Reports to: the board · Status: idle, ready

Every one of the 1,172 agents has written instructions like these, editable in the product. Leads get the full four-file bundle; specialists start from a shorter one, written the first time they run.

Stage 3 · The work

They argue it out on a shared board

The specialists work on a common blackboard. One proposes, another challenges, a third builds on what survives. The plan asks questions and never assumes the answer, and every proposed action has to name the fact it rests on. You can watch it live, and stop it at any moment.

Proposed
Challenged
Built on
Example working
Kill switch
Running

What's built

  • Blackboard workingAgents post to, challenge and build on one shared record instead of passing notes down a line.
  • Budgets and spend capsPer firm, per agent, per piece of work. A breach stops the run and is logged.
  • ApprovalsAnything over a risk or cost threshold waits for a human sign-off.
  • Live runs, pauses and a kill switchWatch every run as it happens. Pause any single agent, or use the kill switch to pause every active agent at once.
  • Runs that always stopA watchdog reaps stalled work and checks who claimed it, so nothing hangs or bills quietly.
Stage 4 · The integrity layer

Every key claim is checked, and the result is on record

This is the part a single chat with a frontier model doesn't have. Every key claim gets an ID and is checked against the source it cites. When a source can't be opened, or doesn't settle the point, that is recorded too rather than hidden. A gate stops a thin answer passing as a complete one. A second reader goes through the draft sentence by sentence. Nothing is delivered until verification has finished, and the whole record is sealed so it can't be quietly changed afterwards.

Example claims from this brief · select one to follow it

    What's built

    • Claim spineOne ID per claim, carried from the first draft to the delivered document.
    • Source verifierEach claim checked against its cited source. Four outcomes: confirmed, contradicted, partially supported, or provisional while still moving.
    • Coverage gateChecks the answer covers what was asked. A short answer can't pass as a complete one.
    • Second readerEvery point that matters is corrected, kept with a recorded reason, answered by the document, or stated in it as a limit. Then the checks run again on the text as delivered.
    • Trust ledger and audit chainEvery step of a run and every approval recorded, each entry sealed to the one before it with a keyed hash.
    Coverage gate 5 of 5 parts of the brief answered
    Contribution, catchments, exit cost, the counter-case and a recommendation. Miss one and the document cannot ship as complete.
    Second reader Every point gets an outcome
    Halo sales understatedCorrected
    Lease data is 2025Stated as a limit
    Why not 20 stores?Answered by the document
    Staff cost range is wideKept, reason recorded
    Release gate Holding until checks finish Nothing is delivered while verification is still running.
    The audit chain

    Each entry carries a fingerprint of itself and the one before it. Change any entry afterwards and every link after it breaks. Try it.

    Checking the chain…

    These are real HMAC-SHA-256 fingerprints, computed in your browser with a demo key. Orqestra's chain works the same way, with its key held outside the database. More in the engine room below.

    Stage 5 · The answer

    A partner's memo you can forward as it is

    One author writes the final document, so it reads in one voice rather than as stitched sections. The answer comes first, then the "so what", then one line saying how much of it was checked. The workings sit in an appendix for anyone who wants them.

    Memo · Store estateExample output

    Close 11 now. Test the other 19 before deciding.

    Eleven of the 30 stores lose money after allocated costs, sit in catchments where online already reaches most customers, and have leases ending within 18 months. Closing them frees capital with little sales leakage. The other 19 carry meaningful halo sales online; closing them would cost more online revenue than it saves.

    So what

    Treat this as two decisions, not one. Bank the easy 11 at lease events, and run a two-quarter test on the 19 before committing the online budget.

    ● 14 of 14 key claims checked against sources: 13 confirmed, 1 could not be fully confirmed. Before sending to a client, review the 1 point flagged in the appendix.
    1. What the 30 stores really contribute
    2. Where online already does the job
    3. The cost of getting out
    4. The case against, and why it doesn't hold for the 11

    What's built

    • Single authorOne writer for the delivered document, with its own checks on what it writes.
    • Answer first, workings in an appendixSet as a partner's memo. The reader gets the decision on page one.
    • One confidence lineSays exactly how many claims were checked and what they came back as, and what to review before it goes to a client.
    • Evidence packOne record per fact, each with its source and verdict.
    • Shareable page, PDF and emailA public page that shows its own verification, a clean PDF, and the finished document emailed to whoever asked.
    Range · One engine, many kinds of work

    Not just memos

    The memo is the easiest thing to show, so it's the one people see. The same engine plans implementations, builds board packs and diligence, runs recurring work on a schedule and watches markets. Whatever the output, it goes through the same team, the same checks and the same record.

    Ready-made work types in the product

    50 outcome templates, grouped by the kind of work, plus multi-part packages.

    Multi-part packages

    Output formats include reports, memos, research briefs, strategy papers, deck outlines and emails.

    Featured · Implementation planning

    Oracle Fusion, planned in Oracle's own order

    Orqestra reads Oracle's published Fusion Setup and Configuration Registry and turns a short brief into a reviewable setup plan. Below is a real plan it produced for Payables, from a fictional sample brief: "Set up Payables for Northstar Retail UK, GBP, 30-day payment terms, invoice approval before payment."

    50setup tasks, in Oracle's order
    5/5mandatory tasks covered by Oracle's rules
    43listed with no guidance invented
    4cross-task dependencies found
    2order conflicts flagged for a human
    0model calls: fixed rules, repeatable
    Oracle rulesPartial rulesCatalogue only★ named in the brief

    What it flagged for the specialist

    • 43 of 50 tasks have no registry rules. They are listed in Oracle's order with no guidance invented for them.
    • Oracle's catalogue puts Manage Payment Options after Manage Invoice Options, but Invoice Options depends on it. Decide which goes first.
    • The same conflict between Manage Payment Options and Manage Bank Charges.
    • Some rule files couldn't be read in full for three tasks. Each section says what was skipped.
    • Every line marked as an interpretation is Orqestra's reading, not Oracle's guidance.

    Its stated boundaries

    • Planning only. No Fusion configuration has been performed.
    • No Oracle credentials were requested and no Fusion environment was called.
    • No model was called. Fixed rules applied to Oracle's published catalogue.
    • Pinned to the FSCR 26D release, with every Oracle file checksum-verified.
    • Each plan gets a trust ledger, sealed into the audit chain. A human specialist stays accountable.
    Featured team · ERP implementation practice

    A systems integrator's programme team, as 32 agents

    Staffed the way a tier-one integrator runs a cloud ERP programme, whether the platform is Oracle Fusion, SAP S/4HANA Cloud, Dynamics 365, NetSuite or Workday. Every design decision cites the vendor's published setup task, or says plainly that it rests on judgement. A Design Authority keeps the signed-off decision record, so you can see who decided what, on what evidence.

    Programme leadership8

    • ERP Programme Director
    • Solution Architect
    • Design Authority & Sign-off Officer
    • PMO Lead
    • Change & Adoption Lead
    • Data Migration Lead
    • Integration Lead
    • Test Lead

    Functional leads12

    • General Ledger & Enterprise Structure
    • Payables
    • Receivables & Collections
    • Cash Management & Banking
    • Fixed Assets
    • Indirect Tax
    • Procurement & Sourcing
    • Projects & Grants
    • Inventory & Costing
    • Order Management
    • Core HR & Payroll
    • Planning & Management Reporting

    Technical bench5

    • Data Migration Analyst
    • Integration Developer
    • Security, Roles & Controls Analyst
    • Reporting & BI Analyst
    • Environment & Release Manager

    Delivery6

    • Business Process & Fit-Gap Analyst
    • Test Analyst
    • Training & Communications Lead
    • Cutover Manager
    • Hypercare & Service Transition Lead
    • Vendor, Licensing & Commercial Analyst
    Independent Assurance Reviewer. Reports to the Programme Director, not to the people whose work it checks, so its view of the programme stays honest.

    Comes with standing routines for the daily programme stand-up, the weekly Design Authority, a weekly data quality scorecard and the weekly status and RAID review. They arrive switched off, and you choose which to run.

    Recurring workRuns on a scheduleRoutines run work on a timetable or when something happens, from a weekly signal brief to a daily standup digest across the team.
    Standing teamsOperations, not just answersReady-made teams for sales operations, content, market intelligence and launches can run on routines, inside the same budgets and approvals.
    MeasurementScores and baselinesAn AI visibility team scores how ready a business is for buyers who shop through AI agents. The baseline can be re-run to track change.
    Capability comparison · Not a benchmark

    What Orqestra adds on top of any model

    Orqestra runs on Claude, so it starts with the reasoning and writing of a frontier model. Every row below the first is something the platform does around the model. A model used on its own doesn't do these things, whichever lab built it. Some providers' own apps cover parts of a few rows, such as scheduled tasks or research with citations; the note under the table says how to read that.

    How to read this. ✓ means the capability is built in. – means the model doesn't provide it when you use the model itself. Some providers' own apps add features such as research modes, projects or agent tools; this table compares the models, not those apps. It describes what is built in, not measured scores, and makes no claim that Orqestra's answers beat any model's.

    Models and order: the BenchLM top 20, last verified 6 November 2026.

    A real run, replayed

    Thirty-one minutes, on the record

    The six-stage journey uses an illustrated example. This does not. It's the recorded event log of a real brief run on 2 October 2026, replayed exactly as the platform wrote it down.

    Real brief · asked through the front door Is UK veterinary practice consolidation still an attractive buy-and-build play for private equity in 2027, given the CMA's market investigation?
    30:42
      What the run did
      Release gate · 12 checksGraded: draft

        The gate would not call this client-ready, and said so on the document. In one place the summary claimed more than the body carried, and four sentences sounded surer than their evidence. It flagged the problems on the document itself, before anyone could send it.

        Not just documents · built under governance

        An afternoon, a finance system, and a team that failed its own build

        On 7 November 2026, nine agents from Orqestra's ERP implementation practice built a working finance core for a fictional UK wholesaler: ledger, payables, receivables, VAT return, statements and month-end close. A person sequenced the stages and signed the two gates. The agents did the work, and the record below shows everything they got wrong on the way.

        9agents, each confined to its own files
        3faults the developer's own tests missed, caught by the Test Lead
        117tests passing, re-run by the platform and sealed
        £5model spend for the whole programme, about
        1. Scope
          Programme Director sets outcomes and acceptance criteria. Solution Architect designs the data model and posting rules. Three functional leads write the module specs.
        2. Gate 1
          Design Authority compiles the decision register and names the five riskiest decisions. A human signs them, sealed in the audit chain.
        3. Build
          Integration Developer builds the system and its own 34 tests. All pass.
        4. Test
          Test Lead writes 69 independent acceptance tests. Three fail, including a way round a control the human had signed.
        5. Assurance
          Independent Assurance Reviewer checks the HMRC references against gov.uk, corrects a wrong citation, and fails the build. It also records that the signed register was rewritten after signature.
        6. Fix
          The developer fixes the faults and escalates a conflict rather than editing the tester's tests. The Programme Director rules. Retest: 77 of 77 and 40 of 40.
        7. Gate 2
          Assurance moves to pass with conditions. The human signs final acceptance: every file fingerprinted by the platform and frozen, tests re-run by the platform itself, all sealed.

        The run also exposed four gaps in Orqestra's own governance, among them that a signed document could be edited afterwards. All four were fixed and proven the same day. That is the point of the record: it shows the failures, not just the finish.

        Open the finance system Read the build record
        Stage 6 · The receipts

        Every brief keeps its receipts

        A partner has to be able to show their working months later. Orqestra keeps the full record of every run, what it cost and what it relied on, so an answer can be defended, audited or reopened.

        CostTrue cost per briefEvery model and tool charge tied to the agent, the run and the brief that caused it, shown in pounds.
        RecordThe full run historyEvery attempt, every hand-off and every decision, in order, with nothing secret written to a log.
        EvidenceLedger and chain on fileThe trust ledger and its hash chain sit with the document, so anyone can check it later. Runs since 7 November are sealed with a key.
        For the technical reader · Under the bonnet

        The engine room

        Everything above is the experience. This is what it takes to deliver it: a full multi-tenant platform, built and hardened over hundreds of iterations, with the quality controls written into the code rather than into a prompt.

        399klines of TypeScript, excluding tests
        198server service modules
        756automated test files
        101database migrations
        74interface pages
        1,172agents on the bench

        Counted from the codebase on 7 November 2026, excluding build output and copied third-party files.

        Architecture

        Seven layers, top to bottom. Select any component to see what it does.

        Select a componentEach one is a real part of the running system.
        How an audit entry is sealed
        Entrywho · what · target · payload · time
        +
        Previous fingerprintthe row before it in the chain
        +
        Secret keyheld outside the database
        ↓
        HMAC-SHA-256this row's fingerprint, stored with it

        Why it's built this way

        • Keyed, not just hashedA plain hash can be recomputed by anyone who edits the data. A keyed HMAC can't be forged without the key, and the key never sits in the database.
        • A stolen backup proves nothingThe key is pushed in per transaction and kept out of logs and backups, so a copy of the database alone can't rewrite history.
        • The whole chain is walkedVerification checks each link against the entry before it and binds every timestamp, so deleting or back-dating a row breaks the chain.
        • Append-onlyEntries can be added, never edited or removed, and the key carries an ID so it can be rotated without breaking older entries.
        RepeatabilitySame brief, same shapeStructure invariance checks that two runs of one brief produce the same skeleton of argument, so quality doesn't depend on a lucky roll.
        Deterministic outputRules enforced in codeFormat, figures and claim states are checked by the platform, not left to the model's good behaviour. Totals must add up; a sized figure must rest on a sourced input.
        Self-auditAttacked by its own auditA 34-subsystem audit went looking for ways each control could lie. Its findings were fixed in batches and re-tested, including a flaw in how the audit chain itself was checked.
        In short

        The orchestra stays behind the curtain. What you hear is the answer, and you can check its working.

        Request a demo

        See it work on a question you actually have

        Tell us a little about you and the kind of question you'd bring. We'll come back to arrange a session where Orqestra works a real brief live, with the integrity layer on show.

        We use these details only to reply to you. Privacy notice