What we can do
Ten claims about the work, each with the part that is harder than it looks and the edge where it stops. Written to be argued with.
- Models on hardware you own
- Answers scoped to who is asking
- Assistants that finish the task
- Walls and a logbook
- Approval bound to what was reviewed
- Figures calculated, never generated
- Documents in, finished files out
- Narrow connections into live systems
- Fast answers, heavy jobs behind them
- Stages that stand alone
We run capable language models on hardware a business owns, so its data has nowhere to go.
The sizing runs in the direction people do not expect. The model is chosen from what the work demands, and the hardware follows from what that model needs to hold a full working context and still answer fast enough that a whole team using it at once does not feel a queue. Choosing hardware first and fitting a model to it is how a business ends up owning something that is technically private and too slow for anyone to use.
It does not mean cheaper. Owned compute wins on control and on predictability, and at low volume a rented API is less expensive. It also does not mean a model trained from scratch.
Assistants answer from the material a business already holds, and only from the part the person asking is allowed to see.
The index is the leak nobody plans for. A search index built over everything will answer about everything, so permissions have to survive the trip from the source system into the index and back out at query time. Filtering results after retrieval does not work: by then the model has already read material the asker cannot see. Two other things decide whether this is usable, and neither is the retrieval itself. What the assistant does when the material does not answer the question, and what happens to its answers when the underlying documents change. Both failures are invisible to the person reading the answer.
It does not cover material the business does not hold. Where the corpus is silent, the honest answer is that it is silent.
We build assistants that carry a task to a finished result, not ones that describe what could be done.
Deciding what to do is the easy half. The difficulty is in three things nobody demonstrates: recovering when a step fails halfway through a plan, knowing when to stop, and knowing when the right move is to hand back to a person instead of trying a fourth time. An assistant that cannot do the third will eventually do something confident and wrong.
It does not mean unattended. Anything that changes data stops for a person, which is a separate capability and a deliberate limit rather than a gap.
An assistant that acts gets walls and a logbook: it reaches only what it was given, and every step it took can be read back.
Two things decide whether this is real. Isolation has to hold on the failure path, so a task that hangs or is abandoned is torn down as reliably as one that finishes, and that is the case nobody builds first. And a usage limit has to slow work down rather than end it, because a hard cap destroys precisely the productivity it was bought to protect, at random, for whoever was working when the ceiling arrived.
It does not cover approving individual actions, which is its own discipline and is listed separately.
Where an assistant changes something, a person approves the exact thing they saw, and the approval dies if the data moves.
Approval bound to a category is the failure, and it is the common one. "Yes, delete files like these" widens quietly behind the reviewer while they are reading. "Yes, delete these" does not. The second is harder to build and it is the only version somebody will actually put their name to.
It does not make a risky operation safe. It makes it signable, which is a different and usually more useful thing.
When an answer contains numbers, ordinary code works them out. The model writes the sentence around them.
The discipline is in the detection, not the calculation. Knowing that a request has become arithmetic when it arrived as a sentence is the part that has to be right, and getting it wrong is invisible. A plausible wrong number reads exactly like a right one, and it reads that way to the person who is about to send it to a customer.
It does not cover judgement that happens to involve numbers, such as which of two options reads better. It covers arithmetic.
We turn the documents a business actually receives, scans and photographs included, into files it can use.
The work is in what arrives, not in what is produced. Real documents are skewed, partial, photographed at an angle, and inconsistent between senders, and a pipeline built against clean examples fails in its first week of real input. Anyone can demonstrate this on a sample. The question worth asking a supplier is what their pipeline does with the worst thing they have seen.
It does not cover documents whose meaning depends on knowledge the business has never written down.
We connect assistants to the systems a business runs through narrow connections that do one job each, never broad access.
The ordinary engineering is the hard part, and it is what decides whether a connection can be trusted to write as well as read. What happens when a sync misses. Whether a retry writes twice. How a disagreement between two systems gets reconciled rather than papered over. Broad access is faster to build and it is the reason most integrations can only ever be allowed to read.
It does not cover systems with no interface to build against.
Short requests answer straight away and long ones run behind them, so one heavy job never makes everyone wait.
The rule that makes it safe is that a slow answer is never handed to somebody who has since asked something different. A nearly-right answer delivered late is worse than a slow one, because by the time it arrives it has been read as current, repeated to a customer, and turned into a promise somebody has to break.
It does not make heavy work fast. It stops heavy work from being everyone else's problem.
Every stage of a build ships something usable the day it lands, and the riskiest stage is not the one everything waits on.
It requires deliberately deferring the most valuable capability. The part that reaches into a business's own systems is worth the most and carries the most exposure, so it goes late, behind stages that are already delivering. Doing the valuable thing first is the instinct, and it is how a build spends its riskiest weeks before anybody has seen it work.
It does not mean fast. It means nothing is stranded if the schedule moves.