framework pillar
Why most AI projects start in the wrong place
There are two things an AI agency can offer you. Most businesses try to do both at once, from the start, with no structure. That is usually why they stall.
There are two things an AI agency can offer you. Most businesses try to do both at once, from the start, with no structure. That is usually why they stall.
We hear a version of the same conversation fairly regularly.
A business leader has seen the demonstrations. They have read the reports. They believe, correctly, that AI should be doing something useful in their organisation. So they commission a project. They describe what they want in broad terms. A vendor agrees it is achievable. Work begins.
Six months later, the thing that was built is not being used. Or it is being used by three people when it was supposed to be used by thirty. Or it was built for a workflow that turned out not to be the bottleneck.
The money was spent. The technology worked as advertised. The project still failed.
The failure is almost never about the AI. It is about the sequence.
Two planes of engagement
When we think about how an organisation actually adopts AI (not in theory but in practice, across a team, in a live operational context), there are two distinct planes of engagement.
The first is what the agency does with you: the service relationship, the capability transfer, the work of making your team genuinely effective at directing, deploying, and governing AI in your context. This is what we call the Capabilities plane — the three service lines of Educate, Build, and Run.
The second is what products support the process: the software layer that helps you scope the right automation, provision agents with appropriate governance, and operate them in production over time. This is what we call the Solutions plane — Workflow Compass, Wrought, and Operations Console.
Most businesses try to live entirely in one plane or the other. They buy a software product and assume it handles the change management. Or they engage a consultancy and assume the work will stick without any operational infrastructure to support it. Neither approach holds.
The two planes are distinct, but they are designed to work together.
The Capabilities plane: Educate · Build · Run
The Capabilities plane is the service layer. It is how we work with your team directly.
Educate is the fluency work. Before your team can use AI agents effectively (really effectively, not just experimentally), they need a working model of how AI agents function, what they are good at, where they require oversight, and how to direct them clearly. This is not a product demo. It is a capability shift. A team that has done the fluency work gets more from every tool they use, makes better decisions about what to automate, and takes appropriate ownership of AI outputs rather than treating them as black boxes. The fluency work is the fastest path to an organisation that uses AI confidently on real work.
Build is the build work. We take a specific workflow (scoped carefully, with clear acceptance criteria) and build the agent or pipeline that handles it. On your infrastructure or ours, on whichever AI provider fits the task. The build is tested on your actual work, against criteria you define, before anything goes to your team or your clients. Nothing ships without passing your gate.
Run is the operational work. An AI agent that worked when it was built can degrade over time, as models update, data patterns shift, workflows change, and regulations move. Run is the managed layer: we operate the system, monitor it against the quality standard you set, and update it as your context changes. The tool stays useful because someone is accountable for keeping it useful.
These three lines are not a mandatory sequence. Some organisations start with Educate to build the foundation. Some come directly to Build with a specific problem scoped and ready. Some inherit a deployed system and need Run. The entry point depends on where you are, not where we prefer you to start.
The Solutions plane: Workflow Compass · Wrought · Operations Console
The Solutions plane is the product layer. It is the software that supports the adoption process across the lifecycle.
Workflow Compass addresses the scoping problem. Most AI projects fail at the point of selection — they build the wrong thing first. Workflow Compass is a structured scoping tool: it maps your candidate workflows, scores their automation fit, identifies which ones will actually deliver value versus which ones look interesting but depend on edge cases that are hard to automate, and produces a build specification for the workflow worth prioritising. The outcome we scope toward is an organisation that builds the right thing first, with evidence, rather than learning which one to build through a failed attempt.
Wrought addresses the build problem. Once you know what to build, Wrought provisions it from tested templates: governance configured at deployment time, acceptance tests built in, MCP connectivity wired, provider selected. The governance is not a retrofit. The audit trail is not an afterthought. The outcome we scope toward is an organisation that ships production-ready agents faster, without the corners that get cut under time pressure and cause problems later.
Operations Console addresses the operational problem. A single agent in production is manageable. A fleet of them, across teams, workflows, providers, and cost centres, requires a different kind of infrastructure. Operations Console is the unified management layer: the schedule, the policy enforcement, the cost visibility, the compliance reporting, and the intake channel back into Wrought when something needs to be updated or replaced. The outcome we scope toward is an organisation where every agent in production is visible, governed, and accountable, rather than a collection of individual deployments that no one has a full picture of.
The three products map onto the Educate · Build · Run lifecycle — Workflow Compass for the scoping phase, Wrought for the build phase, Operations Console for the run phase. But they are also independent tools. An organisation that has already scoped its automation roadmap does not need to start at Workflow Compass. An organisation that already has agents in production can start at Operations Console. The lifecycle is a frame, not a prerequisite chain.
Beneath all three products: an AI Observability layer that surfaces the signals that matter (latency, quality drift, cost patterns, anomalies) across every agent in the fleet, regardless of which provider runs it. And MCP connectivity, the open standard that wires each agent to the data sources and services it needs at provisioning time, rather than as custom integration work on each build.
Why the two planes together
The Capabilities plane without the Solutions plane is consulting that produces output but no infrastructure. The team learns; the knowledge lives in slide decks. The agent gets built; no one is accountable for what happens to it in six months.
The Solutions plane without the Capabilities plane is software that gets purchased and under-used. The tool is available; the team does not have the fluency to direct it well. The governance features are there; no one has been through the workflow of actually using them.
The two planes are designed to solve the problem together. The service work and the software layer are both aimed at the same outcome: an organisation that can adopt AI effectively, not as a one-off project, but as a repeatable operational capability.
The methodology that runs through both
Both planes are built on Anthropic's AI Fluency framework: Automation, Augmentation, and Agency, across Delegation, Description, Discernment, and Diligence. It is the methodology layer that runs through every service engagement and every product we build. We cite it; we do not rebrand it. The framework is theirs; Educate · Build · Run is ours.
The framework is published under CC BY-NC-SA 4.0 by Rick Dakan, Joseph Feller, and Anthropic. We use it as our methodological foundation; we have no claim to ownership of the framework itself.
A note on the model question
The organisations we work with have already made commitments — to their cloud provider, to their internal data governance model, to existing tooling. We do not require those commitments to change. If you are already on a specific AI provider, we build on yours. If you do not have a provider relationship and do not want to manage one, we host and run it for you. We recommend the model that fits the task and show the evidence for the call.
If you are thinking about where to start → Book a scope consultation
If you want to understand the full framework → How it works
If you want to see the products → Solutions