AI PROPERLY EMBEDDED
We design and build AI into products where it earns its place. Inside the workflow, bounded by the rules of the domain, with a person on every decision that matters. Sometimes the right answer is no AI at all, and you will hear that from us first.
The problem
The quickest way to add AI to a product is a chat window, a general model and a system prompt. It demos well. Then real users arrive with real data and real consequences. Nobody can say where an answer came from, what the model was allowed to see, or who approved what it wrote.
In a tutoring product, that looks like a tutor that forgets the learner between sessions. In an HR product, it looks like an investigation record nobody can defend. The model was never the hard part. The hard part is deciding what it may touch, what it must never do, and where a person takes over.
WHAT THE ENGAGEMENT COVERS
Each part opens with the mistake it stops you making. Hover a card for what is actually in it.
PART 01 · WHERE AI BELONGS
Decide where AI earns its place, and where it does not.
Most teams start with a model and go looking for a use. The better start is the work itself: which steps are drafting, synthesis and checking, and which are judgement calls a person has to own.
01 · WHERE AI BELONGS
Workflow mapping, step by step
Task-level calls on what stays human
Data readiness and access review
What it costs to run at real usage
Build, buy, or leave it alone
PART 02 · GUARDRAILS
Design the limits into the architecture.
Governance written after launch ends up as a policy document nobody reads. When the data is about real people, the limits have to live in the permission layer, the retrieval scope and the decision gates.
02 · GUARDRAILS
Bounded retrieval over a governed knowledge base
Decision gates the AI cannot pass on its own
Visibility scoped by role, enforced in the system
An audit trail written as the work happens
Personal information kept out of the AI layer
Model terms, data handling and hosting location
PART 03 · BUILD AND RUN
Put the behaviour in the system, where it can be tested.
A system prompt is the easiest thing to write and the easiest thing to break. Behaviour that matters, such as how a tutor paces difficulty or when an agent has to stop and wait, belongs in the code around the model.
03 · BUILD AND RUN
Agents scoped to one defined task
Retrieval and memory design
Voice, screen and multi-modal input
Editable drafts a person approves before they leave
Integration with the product and data you already run
Production hosting, monitoring and ongoing support
Proof
OLi AI Tutor, Olympus Insights. Olympus Insights is a company Castle co-owns, and OLi AI Tutor is one of its products. We built it as technical co-founders, from commercial strategy through to AI engineering. The tutoring behaviour lives in the system itself: difficulty calibration, Socratic questioning, spaced repetition, and memory that carries a learner across sessions. Learners talk to it and share their screen while they work. Because we co-own the company, we carry the same risk our clients do when an AI feature ships. Read the OLi AI Tutor case study
Nooma, for O-HR. O-HR had a practitioner's methodology for Australian HR and no way to put it in anyone else's hands. We designed and built Nooma, an AI practice companion that walks a practitioner through an investigation or a performance process and writes the record as it goes. The AI drafts and structures. It cannot move a matter forward by itself, and every decision gate waits for a person. Retrieval is bounded to a governed body of Australian employment law and the organisation's own documents, and what each user can see is set by their role. Read the O-HR case study
Questions
Both, depending on the job. Nooma runs on Anthropic models under commercial API terms, with each agent scoped to a single task. For OLi AI Tutor, we built and trained the system that carries the tutoring behaviour. The product, the data and the running cost decide which fits, and we walk you through the trade-off first.
We design data handling in from the first workflow. On Nooma, the model terms prohibit training on customer data, hosting is in Australia, and personal information can stay out of the AI layer entirely. Your setup depends on your data and your obligations, so we scope it with you before anything is built.
Yes. Often the right place for AI is one step inside a product that already works, and everything else stays as it is. We read the product and its data the way an engineer inheriting it would, then decide where AI fits. If the codebase needs work first, you will know before you pay for it.
Then that is the place to start. A lot of the time the better fix is a clearer workflow, a well-built form or a proper report. Strategy & Audit exists for this exact decision, and the written plan is yours whether you build with us or not.
Not the ones that matter. Early in the work we decide which steps are the AI's to draft and which are a person's to decide, and that line is built into the system. On Nooma, nothing leaves the platform as a finished document until a practitioner has reviewed it, and each decision is recorded when it is made.
WHO THIS ISN'T FOR
If the job is a prompt and an API key, you do not need us. If you want a chatbot on the homepage because a competitor has one, we are the wrong studio. Not sure yet whether AI belongs in your product at all?
Start with Strategy & Audit
Tell us what the work is and who does it today. We will come back with an honest view on where AI fits, where it does not, and whether we are the right people to build it.
Software that holds up under real use.
© 2026 Castle Digital. All rights reserved.