Building a Capability: Manifest, Surface, Kernel and Guardrails in Practice
Four parts, kept separate, so you can change the price, the engine or the rules without breaking the agents that call you.
About this page. Aitina Tech’s R&D wing applies the research of Imtiaz Hassan, published as The Software Lens, in client work and in our own product. This page is the applied view: what the pattern is, how we build it, and what an engagement looks like. The full research is on The Software Lens.
To be chosen by an AI agent, your software has to state clearly what it does, what it costs and what it will never do. Built in four clear parts, a capability can change its engine, tighten a rule or move to a new protocol without breaking the customers that depend on it.
From the research
“Run several protocols side by side with sensible defaults, and migrate one capability at a time.”
What we take from it. The four parts are a discipline we hold to on every capability we ship, because they are what let you change a price or an engine without a customer noticing.
How we apply it
Every capability we build has the same anatomy. The manifest says what it does, what it needs and what it costs, in a form an agent can read. The surface is how it is called. The kernel is the logic, which may itself be an agent. The guardrails are the rules it cannot break, enforced at the edge rather than trusted to the caller. Keeping the four apart is what lets you version them separately.
On protocols we are practical rather than partisan. REST stays for the integrations you already have, gRPC earns its place inside platforms that need throughput, and MCP, the Model Context Protocol, is how agents call tools. We expose a capability on more than one surface where the callers differ, and migrate one capability at a time rather than rewriting an estate. This is the day-to-day of our API and MCP development and AI engineering services.
What an engagement looks like
We usually begin with one capability that matters commercially: write its manifest, put guardrails at the edge, expose it over MCP alongside your existing API, and measure it. The pattern then repeats across the estate with your own team doing more of it each time.
The research behind it
This page is Aitina Tech’s applied account of The Anatomy of a Capability and the Protocol Shift, by Imtiaz Hassan, published on The Software Lens. The full argument, the diagrams and the worked examples are there; this page is what we do with it for clients.