AI integration and engineering in South Africa
We put language models, retrieval and agents to work inside real operations, with evaluation, guardrails and a human in the loop where the stakes need one. Senior engineers, based in South Africa, writing the code in your repositories. We also train teams to work with AI, and build plugins that fit AI coding assistants to the way your developers work.
Why most AI projects stall
A demo is easy. Point a language model at a folder of documents and it will answer questions fluently by the end of the afternoon. The trouble starts when the demo meets real operations: the documents are messy, the questions are specific, and a confident wrong answer costs more than no answer at all.
The model is rarely the hard part. The hard part is deciding what it is allowed to see, knowing whether its answer is right, and choosing what the system does when it is not. Those are engineering questions rather than prompt-writing ones, and they decide whether a system can be trusted with a claim, a contract or a customer.
There is one more question a South African business has to answer early: where the data goes. If customer records go anywhere near a model, POPIA goes with them, so consent, retention and access are designed in from the start rather than reviewed the week before launch.
What we build
Retrieval that cites its sources
Search and question-answering over your own documents, policies and records, where every answer points to the passage it came from so a person can check it. When the source is not there, the system says so instead of inventing one.
Document intelligence
Extraction from contracts, claims, applications and invoices into structured data your other systems can use, with the clause or field each value came from attached. Built for the documents you actually receive, not the tidy ones in a demo.
Agents and tool use
Models that take steps on your behalf: look something up, draft a reply, update a record. Our approach is to treat each action an agent can take as a deliberate permission, kept to what the task needs and recorded, with a person approving the ones that matter.
Evaluation and guardrails
A test set built from your own cases, meant to be run whenever the prompt, the model or the data changes, so you can tell whether the system got better or worse. Guardrails set what the model may say and do, and what happens when it is unsure.
AI inside the systems you already run
Most of the value sits in the integration: the model reading from your database, writing into your workflow, and answering to the same audit trail as everything else. We build that half too, because platforms are the other thing we build.
AI training for your team
Hands-on training for the people who will work with AI, from developers using coding assistants to the staff who check what a model produces. It is built around your own tools and tasks rather than generic examples, and covers where the tools help, where they go wrong and how to check their work.
AI coding plugins
Plugins for the AI coding assistants your developers already use, which teach the assistant your standards, conventions and workflow: how the code is laid out, which checks run before a change counts as done, and how the work is tracked. The assistant then works the way your team does, instead of the way a generic one would.
Where it is worth doing
AI earns its place where documents are heavy and decisions are accountable: underwriting and claims in insurance, contracts and obligations in legal and professional services, reconciliation and lending in financial services. In each of them a model may assist a decision, and it should never make one unaccountably.
It does not earn its place everywhere. Sometimes a better search, a rules engine or a cleaner form solves the problem more cheaply and more predictably. If that is the honest answer, you will hear it from us in the first conversation.
How an engagement runs
Start with the decision, not the model
A call with the engineers who would build it, or a First Pass if you would rather gauge it first. We want to know which task or decision the system supports, what it costs when it gets that wrong, and what data it would need to see.
Test the approach on your data
Where we can, we would rather try the approach on real examples from your operation, and agree with you what success looks like, before anyone commits to a full build. We would rather spend two weeks proving an approach than eighteen months discovering it was wrong.
Build in your repositories
The people who scope the work are the people who write it. You see commits in your own repositories from the first week, with decisions recorded where the code can be read against them. The aim is for the evaluation set to grow alongside the system.
Hand over, or keep us on
The code, the infrastructure, the accounts and the documentation are yours from the first commit, the prompts and the evaluation sets included. Once it is live we can hand it to your team, or stay on to maintain and extend it as the models and your operation change.
Capabilities
AI engineering
Most AI projects fail on the unglamorous half: what the model is allowed to see, how you know it is right, and what happens when it is not. We build retrieval that cites its sources, evaluation you can point at a board, and workflows that degrade honestly instead of inventing an answer.
- LLM systems
- RAG pipelines
- Agents & tool use
- Evaluation & guardrails
- Document intelligence
- AI training
- AI coding plugins
Architecture & strategy
Before anything is built: what to build, what to buy, what to leave alone, and what it will cost to run. We would rather spend two weeks proving an approach than eighteen months discovering it was wrong.
- Discovery
- Technical due diligence
- System design
- Delivery roadmaps
Find out if it is worth building
Describe what you want to put AI into, answer five questions, and First Pass gives you an honest verdict and a first brief in minutes, before you talk to anyone. Or request a call: thirty minutes with an engineer, not a salesperson, and a straight answer about what it takes, including whether you should build it at all.