AI across the company
A short assessment per department: which tasks a model can take, what each costs to run and to get wrong, and in what order to roll them out.
Read the full note →AI that your teamcan run and defend
Assistants that cite their sources, agents with permissions, and models that run inside your own walls when the data cannot leave. Designed, built and handed over so your people operate them without me.
What I build
Six things, each with a boundary.
Teaching people to use it well
Hands-on sessions on your own documents and tasks, so people leave using the tools well: and knowing where not to trust them.
Read the full note →Assistants that answer from your documents
Assistants that answer from your documents and show the passage they relied on; when nothing supports the question, they say so instead of inventing.
Read the full note →Agents that do the work, within limits
Agents that do the work, tickets, documents, systems, through a tool surface with explicit permissions and an audit trail of every action.
Read the full note →Models that run on your own servers
For sectors where the data cannot leave: health, legal, defence, anything under GDPR or an NDA. Open models on your hardware or private cloud, behind the same API as the hosted providers, so nothing is shared with a third party.
Read the full note →The right size of model for each task
The smallest model that passes your own evaluation set, measured in cost per case and latency: not the largest one available.
Read the full note →
A practical case
Several agents on one task, and one of them only reviews.
One model writing code into your repository is a demo. What holds up is a small crew with separate jobs, prompts and permissions. It is how this site itself is built.
01
A planner that does not touch the files
The strongest reasoning model reads the real code, in read-only, and writes the plan: files, order, acceptance criteria, what must not be touched.
02
A cheap executor, on a plan it cannot invent
A cheaper model applies the plan step by step: an order of magnitude less per task, and reliable precisely because it is not deciding anything.
03
A reviewer with a different system prompt
A third model, with instructions that reward finding defects, reads only the diff and never edits; its findings are checked against the code before anything changes.
How an engagement runs
Three steps, and you can stop after any of them.
01
Assessment
A short, paid pieces of work: what you are trying to do, what the data and the regulation allow, and whether a model earns its place at all. It ends in a written recommendation, including the one that says do not build this.
02
Prototype under real constraints
Not a demo on curated inputs. The prototype runs against your actual documents, your actual permissions and your actual edge cases, because those are what decide whether the idea survives.
03
Production and handover
Deployment, monitoring, the evidence the regulation asks for, and documentation written so your team can maintain it without me. A system only I can operate is a liability, not a delivery.
If the hard part is the system around the model, that is the work I want.
Tell me what you are trying to do and what constrains it. If a model is not the answer, I will say so in the first conversation.
sanix@sanix.dev
Retrieval · Agents & MCP · Integration · Governance · Evaluation