Model the checklist as obligations
Each diligence item becomes an object with its evidence requirements, so a document resolves the items it can satisfy.
Use case 26 of 28
dataroom → risk → finding → memo
Diligence is thousands of documents assessed against one framework. The checklist, the risk taxonomy and the findings already confirmed are re-sent per document, so the cost scales with the dataroom rather than with the risk in it.
Where the spend goes
This is the shape of the problem in AI due diligence: a pipeline where each step re-establishes context the previous step already had.
What we do here
Each diligence item becomes an object with its evidence requirements, so a document resolves the items it can satisfy.
A confirmed finding becomes a fact with its evidence, so the next document resolves what is still open instead of everything.
Legal, financial and technical workstreams resolve different slices of the same model without sharing each other's context.
The memo resolves findings that carry their source documents, so the trail from claim to evidence survives.
The context each agent gets
Each one is a set of objects with relations, not a section of a prompt. An agent asks for what its task needs and receives that much.
The layer underneath
Most AI products keep business knowledge as prompt text — long strings pasted in front of every call. Text has no structure, so nothing can be selected out of it. The only available move is to send all of it, every time. ensemble models the same knowledge as objects with typed attributes and explicit relations, and objects can be queried.
A prompt preamble
Everything the agent might need, concatenated and re-sent. It cannot be narrowed, because there is nothing in a paragraph to select on. Cost grows with how much your business knows.
A resolved context
Exactly the objects this agent needs for this task, assembled at call time. Cost grows with the complexity of the task, which is the thing your customer is actually paying for.
What the thing is — a product, an account, a campaign, a policy, a prior decision.
Who it belongs to — this tenant, this customer, this department, or everyone.
When it was true, what superseded it, and which version applied at the moment in question.
Validated fact, inference, or unverified claim — so an agent knows what it is standing on.
Which kind of task the fact is actually useful for. Most knowledge is irrelevant to most tasks.
Multidimensional means every object carries those five axes at once, and a request resolves along all of them. In AI due diligence, that is the difference between sending the whole business and sending 6 kinds of fact, filtered to the task in front of the agent.
How it integrates
No model change, no framework migration, no rewrite of your agents. The only thing that changes is where the context comes from.
Audit
You send 100 production runs. We measure token usage per agent, how much of it is repeated business knowledge, and what a completed task costs today. Read-only — nothing is integrated yet.
No integration · Free
Model
We build the object model of your business logic from what you already have — databases, documents, existing prompts and the production runs themselves. This is where the pipeline below earns its keep.
Weeks, not quarters
Route
Replace the place where your agents assemble context with one resolve call. Run it side by side with your current prompt first — same outputs, fewer tokens — then cut over.
Shadow mode first
const context = await ensemble.resolve({
agent: "reviewer",
task: "assess_document",
subject: { deal: project-atlas },
});
// context.block is the resolved business knowledge —
// typically a fraction of what you send today.
const answer = await model.complete({
system: context.block,
messages,
});
// every resolution is metered
context.usage; // { tokensIn, baseline, saved }Who builds it
25+
Years building complex systems where the business logic — not the interface — was the product
Structuring a company's knowledge into objects that an agent can query is not a prompt-engineering exercise. It is domain modelling, and doing it by hand is why most teams never get past a prompt preamble.
We built an automated pipeline for it. It reads a product — its code, its data, its documents and its actual production runs — and produces a visual model of the business logic inside: the entities, the rules, the relations and the places where agents are re-deriving something the system already knows.
That model is the deliverable you can look at and argue with, and it is also the thing your agents resolve against. Both come out of the same pipeline, which is why the timeline is weeks rather than a consulting engagement.