Expertise
AI systems that survive the first timeout
Most AI programmes we are asked to look at already have a working demo. What they do not have is a way to score an answer, a permission boundary, or a process that survives a restart. We build the system around the model, starting from the scoring.
Evaluation
The first artefact, before any agent code. A programme without a rubric cannot tell an improvement from a regression, which is why so many of them stall after the demo with everyone arguing from anecdotes.
- A written rubric agreed with the people who will judge the output
- Ground truth you own, held in your workspace rather than in a vendor tool
- Offline suites in CI, so a prompt change is reviewed like any other change
- Online scoring on live traffic, because the distribution moves
Retrieval and context
Retrieval is where accuracy is won, and it is mostly an information architecture problem wearing a machine learning costume. Chunking, metadata and permissions decide the answer long before the model sees anything.
- Vector search alongside structured filters, because most real questions carry both
- Chunking shaped by document structure rather than by a token count
- Row and column permissions applied at retrieval, so an answer cannot leak what a query would not
- Context assembled to a budget, with what was dropped recorded
Agents and tools
An agent is a program that decides what to call next. Treating it as one changes the engineering: tools get contracts, calls get authorisation, and the loop gets a bound.
- Tool interfaces typed and versioned like any other API
- Unity AI Gateway for model access, with the catalogue permissions inherited
- Human approval gates on anything that writes, with the wait state durable
- Step and cost limits, so a loop fails loudly instead of expensively
Durable execution
Temporal underneath the runs that take hours, call several systems, or wait on a person. The workflow history doubles as the audit trail, so a regulator asking what happened gets an answer rather than a log reconstruction.
- Model calls as activities, retried without repeating the side effects around them
- Runs that survive a deploy, resuming from history rather than starting over
- Approval gates that can wait days without holding a process open
- Compensation paths for the steps that already committed
Operating it
The part that decides whether the system is still trusted on day one hundred. Somebody has to be able to see what it did, what it cost, and whether last week's change helped.
- Traces that show retrieved context, tool calls and the final answer together
- Cost per run attributed to a team, visible before the invoice
- Regression alerts wired to the eval suite rather than to sentiment
- A rollback that is a deployment rather than an archaeology exercise
What we build
- An eval rubric and a test environment before a line of the agent is written
- Context stores and memory that outlive the process
- Retrieval grounded in your own governed data
- Durable execution on Temporal, so a long agent run survives a restart or a deploy
Ways to start
Named engagements, each with a fixed shape.
Accelerators doing the work.
The parts we stopped rebuilding for every agent programme: a durable runtime, an evaluation harness, and a mutation pipeline that treats an agent like any other actor.
A TypeScript framework for durable agents that deploy to Databricks Apps, Temporal or Cloudflare, and keep running through a restart.
A Databricks adoption accelerator for quality engineering, experimentation, and governed delivery.
The kernel under an enterprise composable architecture. Capabilities publish once as versioned contracts, every mutation passes one governed pipeline, and surfaces render from view contracts they cannot write behind.
Durable agents and the console that watches them. Delivered as AI systems, not as a bolt-on to a pipeline job.
How this is delivered
Data science & AI
Context stores, memory, retrieval and governed agents that survive production.
FAQ
Questions we get asked
Do you build machine learning models?
When the problem needs one. More often the model is not the scarce part. The scarce part is the system around it: where context comes from, who is allowed to touch what, how you know the answer is still right next month. That work is /services/ai-systems.
Can this run without our data leaving our environment?
Yes, and that is the default. Applications and agents run in your workspace under their own service principal, inheriting Unity Catalog permissions. TechFabric Harness at /accelerators/harness is how we deploy that agent as a Databricks App.
What keeps a long agent run from half-completing?
Temporal. We are a Temporal partner and durable execution is what sits under any agent run that takes hours, calls several systems, or waits on a person.
The workflow history is the audit trail, so a run that was interrupted resumes rather than restarts and you can reconstruct afterwards what it did. Four systems we have published run on it, including our own. See /durable-execution.
How do you prove an agent is working?
An evaluation harness with ground truth you own. TechFabric Experiments at /accelerators/experiments keeps that suite running. When the thing being scored is a Genie space, the named engagement is Genie Accuracy at /databricks/genie-accuracy.
Have you put one into production?
Fabric is a production Databricks App with durable workflows and human approval gates, and we run our own company on it. Canvass, which we built for a client, runs the same way on Cloudflare. Across our clientele, delivery work that needed a team of ten now takes three.
How can we help?
A technical conversation with a senior engineer. If the honest first step is writing the scoring, we will say so.