Skip to content
Let's Talk
Field Guide · AI Integrationv1 · 2026

When you say AI,
what do you mean?

Most clients arrive with a sense of urgency and no map. 'We need AI' usually means one of five distinct things, depending on how deep into the stack you want to go. This is the stack. Where you sit on it shapes what we build, what it costs, and where it tends to break.

Premise

“The model is rarely the bottleneck. What sits around the model usually is.”

Most AI projects stall on the same handful of things: the data is unreliable, the agent has access it shouldn't, the prompt is fighting the model, or no one defined what 'working' looks like. Gartner expects 30% of generative AI projects to be abandoned after proof-of-concept by the end of 2025.

Below is a working stack of five layers. Each one is real engineering, each unlocks specific capabilities, and each has its own way of failing without anyone noticing. Reading this won't make you an AI engineer, but it should tell you which layer you're actually asking about.

Five-layer stack overview05Cowork & Orchestrationwhere agents become teammates04Harness & Skillsscaffolding around the model03Agentic Toolingscoped, role-aware access02Vectorizationdata turned searchable by meaning01Data Integrationplumbing your real systems togetherEach layer assumes the one below works
Layer 01

Data Integration

Connecting the systems where work already lives.

The first layer is plumbing. Before a model can do anything useful, the things you already use (Xero for invoices, SharePoint for documents, a CRM for client details, Asana or Linear for project state) have to be reachable, fresh, and permissioned correctly. This is roughly two-thirds of the work in a real AI project, and it almost never appears in the demo.

What this layer enables
  • Weekly reporting that pulls real numbers from Xero, HubSpot, and your project tools, instead of describing what reporting could look like in a deck.
  • Internal search across the documents your team already uses, with permissions honoured at the retrieval layer rather than retrofitted later.
  • The substrate every layer above this assumes. Skip it and everything built on top inherits the same gaps.
  • Workflow automation that triggers off real events (a new lead, an overdue invoice, a tagged document) rather than calendar reminders.
What it won't do yet
  • Answer free-form questions about your documents. That's the next layer, vectorization, and it doesn't come for free.
  • Give an agent the ability to write back into your systems. Read access is one layer; scoped write access is two layers up.
  • Stay useful when data is stale or fragmented across sources. Failures here don't throw errors, they just produce answers nobody can verify, so they rarely get debugged. Teams stop trusting the tool instead.
  • Skip discovery. Connecting the wrong systems faster doesn't help anyone.
Layer 02

Vectorization

Turning your data into something a model can search by meaning.

Once data is reachable, the second layer turns it into vectors: numeric fingerprints where things with similar meanings end up near each other. A model can find 'the contract clause about cancellation' even when the document doesn't use the word cancellation. This is also where the 2025/26 term 'context layer' lives: verified business meaning, identity resolution, freshness, and policy sitting between raw data and any agent that touches it.

What this layer enables
  • RAG chatbots (retrieval-augmented generation), where the model answers from cited passages of your real documents rather than guessing.
  • Semantic search across contracts, policies, internal wikis, and historical client work, by meaning rather than keyword.
  • Deduplication and record matching across CRM systems that disagree about the same customer.
  • Classification and routing: auto-tag tickets, categorise incoming requests, surface anomalies in invoice patterns before anyone notices.
What it won't do yet
  • Make a model smarter. Vectorization is a lookup primitive: it changes what the model can find, and nothing about how well it reasons.
  • Replace business logic. Vectors return what's similar. Whether something is permitted is a rule you still have to write.
  • Save you from RAG over unreliable sources. If your policy documents contradict each other, the chatbot will repeat the contradictions with citations.
  • Act on what it finds. The model can locate the right document; it can't update it, file a ticket, or notify anyone until the next layer is in place.
Layer 03

Agentic Tooling

Giving agents scoped, role-aware access to your systems.

The third layer is where AI starts taking action. Each agent gets a manifest of tools: scoped API endpoints with names like GetProjectDetails or CreateInvoiceDraft. Each tool has internal role-based access control, so a project management agent can see tasks and deadlines but never touches pricing or margin. The protocol most teams are converging on is MCP, Anthropic's open Model Context Protocol, which solved the problem of every model needing a custom integration.

What this layer enables
  • CRM-aware draft assistants that pull client context, past proposals, and pricing rules, draft the email, and never auto-send.
  • Lead enrichment where the model reads (a company's website, a news article) but isn't trusted to invent (a funding round, a headcount).
  • Customer-facing chatbots with scoped tools (getOrderStatus, requestReturn) and explicit refusals on out-of-scope questions.
  • Internal write agents that take real action on your behalf: file a ticket, schedule a follow-up, post a status update, draft an invoice.
What it won't do yet
  • Survive the Air Canada precedent. In 2024 the airline lost a case when its chatbot promised retroactive bereavement fares its policy didn't support. The model wasn't hallucinating; the data layer and the tool scope simply never enforced the policy. Anything customer-facing needs RAG over policy, scoped tools and explicit refusals before it goes near a customer.
  • Stay safe with over-permissive tools. The most common production failure at this layer is an agent inheriting the user's full permissions. Scope each tool to the task it serves rather than to whoever happens to be calling it.
  • Make judgement calls under pressure. Tools execute what they're handed. Deliberation is the next layer up.
  • Be trusted without audit logging. Every tool call has to be traceable. Agents fail in ways humans don't, and you need the trace to find them.
Layer 04

Harness & Skills

The scaffolding that shapes how an agent behaves.

The fourth layer is the harness: everything around the model that turns a single text completion into reliable behaviour. The inner harness lives inside each model call: system prompts, tool definitions, retrieved context, output schemas. The outer harness lives outside: evals, retries, guardrails, observability, human-in-the-loop. On top of both, Anthropic's Skills (released October 2025) are small folders of procedural know-how: a SKILL.md file telling the model how to do something specific, optionally with scripts the model can run. Skills cover procedure, tools cover access, and most real work needs both.

What this layer enables
  • Brand-voice Skills: your tone, structure, and language locked into every draft, not re-guessed each time.
  • Procedural Skills like 'how we run a discovery call' or 'how we structure a creative brief', encoded as repeatable, model-readable steps.
  • Reliable multi-step workflows: research, draft, review, hand off to a human at the right moment, with the handoff defined rather than improvised.
  • Evals: measurable definitions of what 'working' looks like, so you can tell when behaviour drifts before your users do.
What it won't do yet
  • Survive the lethal trifecta. Simon Willison's framing: any agent with access to private data, exposure to untrusted content, and an external communication channel is vulnerable to indirect prompt injection. No alignment fix patches this. The architecture has to remove one leg of the trifecta.
  • Replace judgement. A Skill encodes a procedure. Deciding whether the procedure should run at all is still a person's call.
  • Outperform a strong model by stacking scaffolding around a weak one. Over-scaffolding is the most common failure mode of 2024-era agent frameworks, and it doesn't age well.
  • Stay useful when no one maintains the evals. Behaviour drifts as models update and your business changes, and without evals you hear about it from a user rather than a dashboard.
Layer 05

Cowork & Orchestration

Where agents become teammates.

The fifth layer is what the people in your business touch. Cowork is the surface (Claude Cowork from Anthropic, Microsoft Copilot Cowork running Claude inside the M365 Graph, or a custom front-end built for your team) where a named agent shows up alongside humans with a defined role rather than an open text box: a project management agent for the PM team, a creative strategy agent for strategists, a finance agent for operations. Each one inherits the four layers below it: real data, real tools, real Skills, real evals.

What this layer enables
  • A creative strategy agent that knows your client history, helps draft positioning, and never gets near pricing or contracts.
  • A PM agent that tracks tasks, surfaces risks, and drafts status updates, using the same tools and permissions the human PM has.
  • Cross-team workflows that span the systems your team already lives in (Slack to CRM to calendar) without anyone learning a new app.
  • Adoption that sticks, because the agent fits an existing job rather than asking a team to invent one.
What it won't do yet
  • Make a poorly-scoped agent useful. Agents that try to do everything fail; narrow, named coworkers outperform open-ended assistants by a long margin.
  • Create trust through installation. Teams trust agents they've shaped: ones whose evals they've watched move and whose mistakes they've corrected. That usually takes a few months of real use.
  • Compensate for missing layers. A Cowork-style agent without scoped tools or harness discipline carries the same liability as any other chatbot, with more confidence behind it.
  • Be your only AI work. The integrations that hold up tend to be three or four narrow coworkers rather than one that tries to cover everything.
Constants

What stays the same, regardless of where you start.

AI integration is rarely a single project. It's a sequence of smaller ones. You enter the stack at the point that fits your data and your team. These four constants hold either way.

Discovery first

We map your data, your workflows, and what 'working' looks like before we wire in any model. The projects that skipped it came back and did it later at a higher cost.

Narrow scope

One coworker, one workflow, one layer at a time. We ship something useful before we ship something ambitious, because widening the scope after launch costs far less than untangling an over-scoped one.

Human-in-the-loop

Every write tool starts with a human approval step. We remove it once the metrics say it's safe, which is usually later than anyone hoped.

Ongoing tuning

An AI project needs tending after launch. Prompts, Skills and evals drift as the model updates and your business changes, so we stay involved past launch. If someone quotes you a fixed end date for this, ask them what happens at the next model release.

Where to next

Tell us what you're trying to do.

Tell us the problem you're solving and the systems you're already using. We'll tell you which layer you're actually asking about, and whether it's a project we should take on.

Start the Conversation