How we work.
Method, patterns, and operating model, codified from production systems and re-applied with discipline.
One engagement, twelve months minimum.
There is one engagement, and it begins before there is an invoice. Scope, architecture, and the business case are worked out in conversation. That is business development, not a billable deliverable. We do not sell assessments, because an assessment is not the thing that changes an operation, and a client who has bought only a roadmap has bought the one part of this work that cannot act on its own.
The work starts the day the contract is signed, with analysis and a benefit impact assessment: what the operation needs most, weighed against what can realistically be built and in what order. That is what sets the build priority. The sequence follows the benefit rather than a generic maturity model. There is no separate onboarding stage to buy; that part is administration.
From there we build against the highest-value bottleneck first: the full Business Operating System where that is warranted, a single bespoke system where it is not. Then we run it, on a monthly retainer, with a quarterly review of how the system is performing. The term is twelve months at minimum.
The models are substitutable.
The system around them is not.
The Business Operating System is model-plural. A router sends each task to whichever model suits it, weighing reasoning depth, latency, and cost per workflow instead of settling it once in a procurement meeting. Anthropic, OpenAI, and open-weight models sit behind one interface, and the selection is revisited as the field moves. None of that is remarkable; it is basic competence at the model layer, and we treat it as such.
What is not substitutable is the operating system: the governed tool surface, the orchestration, the composition surfaces where people review and commit, and the audit trail beneath all of it. That end-to-end platform is what an engagement delivers, and it is where the value stays as models come and go. We build in Claude Code every day. That is a fact about how we deliver, not a dependency in your architecture.
So what a client buys is a working system and the accountability for it, not fluency in someone else's tooling.
Each task goes to the model that suits it, weighing reasoning depth against latency and cost per workflow instead of defaulting. Basic competence at this layer, instrumented rather than assumed.
Anthropic, OpenAI, and open-weight models behind one interface. Changing model is a configuration change, not a rebuild, so the architecture never depends on one vendor's roadmap.
Prompts, skills, and subagent definitions are versioned, reviewed, and shipped with the application around them. Nothing is pasted into a console and called deployed.
Enterprise systems exposed through governed MCP servers, an open protocol and the single seam where scope, identity, and audit are enforced.
Every call carries its cost and its measured outcome. Routing decisions are reviewed against real spend and observed quality, not vendor benchmarks.
Behaviour measured against written evals before deployment; safety, refusal, and review surfaces designed in, not appended.
Model vendors build the models and the platforms. We build the operating system, the governance, and the accountability around them, and we never imply otherwise.
Five patterns. Each one battle-tested before it ships.
The library is the firm's leverage. Each pattern is documented, instrumented, and reused. New engagements pay for novelty only where novelty is warranted.
The Gateway sits between agents and the systems-of-record. It enforces scope at the tool level, attaches caller identity, logs every invocation, and rate-limits per-agent and per-tenant. Without it, agents accumulate trust the organisation cannot reason about.
In regulated contexts, the Gateway is the audit surface. Compliance reviews look at it, not at the agent's prompt.
// MCP tool definition — registered on the gateway { name: 'list_invoices', description: 'List unpaid invoices for a tenant.', scopes: ['finance.read'], rate_limit: '60/min', audit: 'full', handler: async (ctx, args) => { /* … */ } }
The Portal Shell is where humans stay in the loop. Agents do the drafting; humans do the review and the irreversible commit. The Shell makes that boundary structural rather than a checkbox.
Every panel renders agent output adjacent to its inputs and audit trail. Approvals carry the reviewer's identity into the system-of-record.
Most clients have ten to twenty services that an agent benefits from reading or writing: CRM, ERP, document store, calendar, billing, ticketing. The template gives each one a consistent MCP surface in under a day of work each.
Naming, scoping, error handling, and audit all share one shape. Agents learn one pattern, not twenty.
Prompts, skills, and subagent definitions are code, versioned, reviewed, and shipped with the same rigour as the application around them. We never paste prompts into a console and call it deployed.
Configuration travels with the engagement: a client receives the full kit, not a black box.
Chat is the wrong default for most enterprise workflows, but the right default for ad-hoc questions, drafting, and explanation. Portal Chat lives inside the Shell, sees the same state the user sees, and routes to the same governed tool surface.
It is not a separate product. It is the conversational facet of the Portal.
The Business Operating System, in five layers.
Our reference architecture is informed by publicly-discussed AI-maturity frameworks, DAIN among them, but the five-layer model below is our own. We name what we built and credit what we built on; we don't claim either as the other.
The Business Operating System, our five-layer reference architecture. The name describes our implementation, not a category we claim to own. Not every engagement uses every layer: a bespoke build may need only the tool surface, the composition surface, and the governance beneath them.
The reference architecture deploys as CLTF, the firm's codified platform, currently in production in our own operations and on selected client engagements. Client-integrated deployments adapt the platform into the client's own infrastructure; hosted engagements run on instances we operate. The platform is the firm's leverage; the engagement is the work.
Agent-native, by construction.
The principle is short: control planes get MCPs, not UIs. Anywhere a tool exists primarily to coordinate work, we expose it as an MCP server and let agents drive it. Anywhere a tool exists for composition or review, the human surface stays.
Internally, the firm runs the same shape: a TobDog scheduler, an EA agent, a business-development agent, a delivery agent, and a CFO agent. They run the practice between client engagements. That is what makes a one-architect consultancy possible without theatre.
Start a conversation.
Scope, architecture, and the business case are worked out before anything is signed. Send a brief with the context of your situation.