Studio experimentDocument intelligence2025
Ledger
A document pipeline that extracts structured records from inconsistent supplier invoices, validates them in code, and routes only its own uncertainty to a person.
Independent AI & software engineering studio
Software that thinks. Systems that hold up.
We design and build intelligent software — AI agents, retrieval and document systems, and the production engineering that keeps them reliable once real users arrive.
- Specialism
- AI agents, agentic workflows, retrieval and document intelligence
- Also
- Full-stack product engineering, APIs, integrations, dashboards
01How these systems actually work
Anatomy of an agentic system.
Most diagrams of an “AI agent” show a brain. This is the part that matters: the stages information passes through, the checks between them, and the point where the system stops and asks a person.
Situation
A finance team receives supplier invoices by email in a dozen different formats and types them into an accounting system by hand.
Trigger
A PDF invoice arrives at the shared accounts inbox.
Step 01 / 08 · Input
Document received
The document enters through a watched inbox. It is stored, hashed and given an identifier before anything reads it, so every later step can be traced back to an exact file.
Illustrative payload
- source
- inbox/accounts-payable
- file
- invoice-scan.pdf · 412 KB
- pages
- 2
- doc_id
- doc_8f21c4
Illustrative only — authored data, no model calls
Structured, validated records reach the ledger. Anything the system is not confident about waits for a person instead of guessing.
Step 1 of 8: Document received. The document enters through a watched inbox. It is stored, hashed and given an identifier before anything reads it, so every later step can be traced back to an exact file.
The anatomy does not change
All three workflows above have the same eight stages. What differs is what each stage is responsible for — which is why the architecture transfers between problems that look nothing alike.
Validation is ordinary code
The checks that make these systems trustworthy are schema parsing, arithmetic and policy rules. They fail the same way every time, and they are unit testable.
A gate is a feature
Every workflow has a stage that waits for a person. Deciding where that stage belongs is the most consequential design decision in the system.
02Selected work
Systems we built to find out how.
Three studio experiments in the problems clients most often bring us. Each one is documented with its architecture, its technical decisions and the things it does not do.
Concept demonstrationConversational analytics2025
Prism
A natural-language interface to a data warehouse that generates read-only queries inside permission boundaries and shows the definition behind every number it reports.
Studio experimentAgentic workflows2025
Relay
An operations workflow that triages inbound requests, acts on the routine ones within written policy, and escalates everything else with its context already assembled.
03Capabilities
AI is the specialism. Engineering is the job.
We lead with AI because that is where the hardest current problems are. We are trusted with them because the rest of the software around them is built properly.
04How we work
Good engineering begins before the first line of code.
These are not aspirations. They are the working rules that decide what we build, what we refuse to build, and what we tell you when something is not working.
- 01
Understand the actual problem
The brief is a hypothesis. We spend the first part of every engagement working out what is really being asked, because building the wrong thing well is the most expensive outcome available.
- 02
Choose the simplest thing that works
A scheduled job, a lookup table and a well-named function solve a surprising share of problems presented as AI problems. Reaching for less machinery is a senior decision, not a lazy one.
- 03
Use AI where it earns its place
Models are very good at ambiguity, language and messy input, and unnecessary everywhere else. We put them where that strength is load-bearing and use ordinary code for the rest.
- 04
Design for the failure, not the demo
Timeouts, duplicate deliveries, partial outages and inputs nobody anticipated are the normal operating conditions of software. A system is only as good as its behaviour on a bad day.
- 05
Build something maintainable
Code is read far more often than it is written, usually by someone without context. Clear boundaries, honest names and written decisions are a deliverable in their own right.
- 06
Measure before claiming
Evaluation sets, traces and instrumentation come before confidence. If we cannot show you how we know something works, we will say we do not know yet.
- 07
Ship it
Software that is not in use is a cost, not an asset. We would rather put a narrow, working version in front of real users than present a complete plan for a system nobody has tried.
05The studio
A small studio, on purpose.
Kalky Labs is an independent engineering studio. The people who scope your project are the people who build it — there is no layer of account management between a decision and the code that implements it.
We take on a small number of engagements at a time. That is a constraint, and it is also the reason we can give a project the attention that difficult problems need. Where something is outside what we do well, we will say so.
Founder profiles · pending
Names, roles and short biographies will appear here once they are finalised. This space is reserved rather than filled, because a studio that invents its own team page is not a studio worth hiring.
06Insights
Notes from the workbench.
Working notes on the problems we keep running into: where confidence scores mislead, why retrieval quality is a ranking problem, and what separates an agent demo from a system you can rely on.
Drafts · not yet published
- Agent reliabilityDraft
Confidence is not a safety mechanism
Confidence scores tell you how certain a model is. They tell you nothing about what it costs to be wrong — and those are different questions that production systems keep conflating.
7 min read - RetrievalDraft
Retrieval is a ranking problem, not a vector problem
Most RAG systems that disappoint are not failing at embedding. They are failing at everything that happens before and after it — chunking, ranking, and knowing when to return nothing.
8 min read - EvaluationDraft
Write the evaluation set before the prompt
An evaluation set written before implementation is a specification. Written afterwards, it is a description of whatever the system already does.
6 min read
07Next step
Have something difficult in mind?
We like ambitious problems — the ones with awkward constraints, messy data and a real cost attached to getting them wrong. Tell us what you are building and what makes it hard.
- Good fit
- A real workflow with real constraints, an internal owner who can make decisions, and a problem where being wrong actually matters.
- Less good fit
- A chatbot with no defined job, a fixed-scope rebuild of something that already works, or a project that needs to look finished before it is understood.