Architecture induction
Senior Katemba architects sit with your team and walk the whole platform, from the isolation model up. Half a day of slides; the rest is in the codebase.
Services · 05 - Platform Enablement
You have engineers. You don’t have months to re-litigate multi-tenancy, audit, persona governance and durable agent runtimes from scratch. Platform Enablement gives you the foundation we use for every Katemba engagement, plus the architects to make your team productive on it quickly.
It’s for organisations that want to own the build internally, for strategic, budget, or operating-model reasons. Typical fits:
What you license
The foundation framework.
An application framework that deploys into your own cloud or data centre, and supports multi-tenancy inside it where the application calls for it. Database-enforced tenant isolation, a registry architecture that keeps your code cleanly separated from the framework, a durable job queue, an event and audit backbone, and a provider-agnostic AI gateway. Industry-standard stack on PostgreSQL. Built to be cloned and owned.
/personasThe governed persona engine.
A service that authors, versions, compiles, evaluates and serves AI personas, skills, domain packs and output contracts. Served over the Model Context Protocol, so anything that speaks MCP can consume governed personas without custom integration.
/runtimeThe durable agent runtime.
A runtime for long-running, resumable agent work: durable runs, work claim queues, checkpoints, plan graphs, and memory. The engine that keeps multi-step AI work consistent and recoverable when a process dies or a deploy lands mid-run.
What enablement includes
A licence to the platform is a starting point, not the whole engagement. A typical Platform Enablement programme adds four things.
Senior Katemba architects sit with your team and walk the whole platform, from the isolation model up. Half a day of slides; the rest is in the codebase.
We build one real, governed application alongside your engineers, on your infrastructure. Pair programming, code review, joint design decisions. The first build is the deepest enablement - your team internalises the patterns by doing.
We translate the platform’s defaults into a set of conventions tailored to your team’s existing standards: repository structure, testing approach, deployment patterns, observability stack.
After the initial build, your team has a named Katemba architect on call for design questions, code review on AI-critical paths, and support through your first independent build.
The end state
Within the typical 8 to 12 weeks of an enablement engagement, your team should be able to do all of this.
You keep the platform, the conventions and the institutional muscle memory. Future Katemba involvement is optional: for new vertical workbenches, for assurance engagements, for managed run, or for nothing.
Why this exists
We’d rather see governed, auditable, owned AI win the regulated-AI market than any specific company.
The platform is the substrate that makes it possible. Some clients want us to deliver the application. Some want us to assure it. Some want their own teams to build on the same foundation. We’re set up for all three.
How we engage
Licence shape and enablement scope are confirmed during Discovery.
We meet your engineering team, look at your stack, agree on the first application to build together, and confirm the licence and enablement scope.
Architecture induction, first joint build, conventions, and the beginning of independent capability.
Ongoing licence, named-architect access, periodic architecture reviews, optional managed run for the operational layer.
If your engineers want to see the platform and the method, we’ll set up a walkthrough.