Engagement Studio · the technology

Making AI safe enough to sign.

An assessment is not a chat. Somebody puts their name on it, and a client or a regulator may read it years later. A plausible sentence is not good enough. This is what that requirement forced us to build.

Why this is hard

A language model on its own cannot do this job.

Not because it is not clever enough. Because of what an assessment has to survive.

The problem

It produces specifics that sound right. A number, a date, a clause reference, all fluent and all invented.

What we built Evidence is an invariant, not a habit.

Every record carries provenance by construction, and no engagement type can switch that off. Evidence is a document citation with the verbatim quote, an answer tied to a named person, or another record. A reference that cannot be resolved downgrades the claim to inferred and flags it for review.

The problem

Across forty documents it quietly picks one version of the truth and moves on. The disagreement disappears.

What we built Contradictions are typed objects, not judgement calls.

A contradiction carries both sides' citations. The disputed record keeps its last confirmed content, reviewers see the warning, the client-facing render never does, and delivery stays blocked until a person resolves it: supersede, dismiss with an audit trail, or route it into the next round of questions.

The problem

One long conversation loses the thread. What was established early is forgotten later, and the same question gets asked twice.

What we built One graph, five narrow agents.

A synthesizer writes the knowledge graph, a planner proposes questions, a composer writes document blocks, an analyst computes one declared output, and a QA agent reads the rendered deliverable. Each returns a patch of typed operations in a validated envelope; the engine applies it in a transaction and rejects any write outside that agent’s lane.

The problem

Prose cannot be checked. A paragraph is either believed or rewritten, and nobody can compare it to last year's.

What we built Findings are records with a state machine.

Every finding, risk, decision and question is a typed node with a human-readable ID, a schema-validated payload and its own lifecycle. New knowledge enters as a draft. A change that would unlock a deliverable enters as a proposal with an old-versus-new diff. Confirmed knowledge is never modified by a machine.

The problem

An agent that decides on its own leaves nobody accountable. And nobody signs what they cannot check.

What we built The engine is the only dispatcher.

No agent ever calls another, and no model decides what runs next: every applied patch is the deterministic trigger for the next step, which makes a run repeatable and auditable. The transitions that matter stay human. A question reaches a client only after review, a finding counts only after confirmation, and delivery sits behind a named approval gate.

The problem

An open-ended agent loop is an open-ended bill. Cost shows up after the fact.

What we built Cost is an engineering constraint.

Token and tool-call ceilings are configuration, not hope. Documents regenerate by dirty blocks, so cost follows the size of the change rather than the size of the document, and every run reports its token spend and cache hits on the activity screen.

How a run works

Human input queues up. One wave processes it.

Agents never react to keystrokes. They run when the consultant says run, over everything that changed.

  1. 01

    Changes queue up

    Answers, new sources, confirmations and new questions accumulate as pending changes. Nothing triggers a model call by itself.

  2. 02

    One wave runs the roles

    The engine runs synthesis, planning, composition and QA in order, over the whole batch. Batching is why thirty answers cost a handful of runs instead of ninety.

  3. 03

    The impact panel shows the diff

    New drafts to curate, proposed changes with old-versus-new, new questions, contradictions. Nothing is applied to confirmed knowledge automatically.

  4. 04

    The render is deterministic

    A delivery renders from the graph with zero model calls: PDF for people, a structured export for the system on the other side. Every snapshot is a new version of the same file.

Where the model choice sits

Models go through one provider layer: OpenAI, Anthropic, any OpenAI-compatible endpoint, or a model running on hardware you control. Changing provider is configuration, not a rebuild, and where a provider’s terms matter to you, the deployment can be pinned to models you host yourself.

The parts that are not specific to this module. Sign-in, access rules, the audit trail, workflow, storage and isolation belong to the system underneath, not to Engagement Studio. That is why they are the same here as in every other solution we run.

Inside Omnicorn
Boundaries

What we deliberately do not do.

Stated plainly, because the omissions are as much of the design as the features.

  • No autonomous delivery. Nothing goes to a client without a named person signing it.
  • No training on your data. Your material runs your engagements and nothing else.
  • No scoring the AI cannot justify. If a finding has no source, it does not get a score.
  • No hidden model switching. You know which provider runs your engagements, and you can change it.

Bring your architects.

We will walk the boundary with them: what the AI proposes, what a person decides, where the record lives, and what leaves your network.

Let's meet