The four building blocks of team AI

Ask a team whether they use AI and most will say yes. Probe for two minutes and you usually find one person with a chat subscription, a pilot nobody has opened since March, and a bot in Slack that answers nothing anyone needed. The statement describes a purchase. It says nothing about capability.

A setup that actually works is describable. You can point at the parts, say what each one does, and name who owns it. That difference is what this piece is about.

I build these systems for a living, for an agency, for a SaaS product, and for my own working week. Stripped of vendor names and framework jargon, every setup that survived contact with real use came down to the same four decisions. What the system knows. What it can reach. How it does repeated work. Who it acts like.

Knowledge, connectors, skills and agents. I have taught this on a whiteboard, scoped client builds with it, and used it to figure out why a promising setup quietly disappointed everyone. This is the long version, because the short version keeps getting nods without understanding.

It did not start as a framework. It started with a practical problem: explaining an agent setup to a room of people who do not think like developers, in one afternoon, without a single vendor slide.

I wrote four boxes on a whiteboard and filled them in with things the team already recognised. Their own client history. The tools the assistant could see. The checks they ran before a quote went out. The person they trusted to send emails. Nobody needed the terminology explained twice, because the blocks were already how they thought about their own staff.

The framework has survived every test since. Explaining scope to a CEO in ten minutes. Diagnosing why a chatbot pilot stalled. Deciding what to build first for a new team. It kept working because it is not a theory about AI. It is a description of what any working delegation requires, applied to a machine instead of a person.

Then, in May, I sat in an AWS Bedrock AgentCore session in Hong Kong and watched their managed agent platform presented. Their architecture separates the agent from its memory, its skills and its gateway. Four blocks, different names, arrived at independently and shipped as cloud infrastructure. When the biggest cloud vendor and a workshop whiteboard land on the same split, that is probably not a coincidence.

Knowledge is everything the model needs that is not in the prompt you just typed. A chat box has amnesia. Every conversation starts from zero. Knowledge is the fix: context that persists and shows up every time.

It splits into three kinds. Standing context: who you are, how you talk, what you sell, what you will never do. Reference material: pricing rules, brand guidelines, past proposals, client history, the decisions you already made. And boundaries: what is confidential, what needs a person's approval, what never leaves the building.

Where knowledge lives matters as much as what it says. Text files in a repository beat a wiki nobody maintains, which beats a PDF someone emails around. Version control matters because knowledge drifts. Prices change, clients leave, policies get updated, and the copy the model reads silently goes stale. If you cannot see when a piece of knowledge last changed, you cannot trust the outputs built on it.

I saw this most clearly with a proposal agent built for a twelve-person agency. The system prompt alone produced plausible, generic proposals. Plausible is the dangerous word. It sounded right and priced wrong. What fixed it was knowledge: the agency's actual quotation standards, their communication principles, the history of what past quotes included and excluded. Same model, completely different output.

How this block fails is easy to recognise. The knowledge goes stale, like last year's rate card. It conflicts, like two documents that disagree about what a revision includes. Or it is siloed, living in one person's head, never written down at all. The symptom you will hear from the team is “it doesn't really get us”. That is a knowledge gap, not a model problem. Buying a smarter model does not fix it.

Knowledge is what the system knows. Connectors are what it can check. Gmail, Google Drive, Notion, the calendar, analytics, the quoting software, the web. Each one turns an answer the model would have guessed into an answer it can verify.

This is the quiet superpower of the block. A model with no connectors answers from memory, and memory is where hallucination lives. The same model with a connector to your documents can say “the scope document says three rounds of revisions” and be wrong in a way you can immediately see and fix. Guessing is only dangerous when you cannot tell it apart from checking.

Connectors need a permission shape, and the shape should be deliberate: read, read and write, always ask first, or never. Default to read. Read access lets the system verify without being able to break anything. Every write permission is a risk you have consciously accepted, and it should stay conscious. The agency proposal agent can read the quotation store and draft exclusions. It cannot send anything to anyone. That asymmetry is the design.

The same build uses a connector policy worth stealing, called a source ladder. Before drafting anything commercial, the agent must work down a fixed order: local files, then Drive, then Notion, then the approved quote templates, and only then the open web. It cannot skip a step, and it must report what it checked and what it skipped. The web sits last because it is the least trustworthy source for a question about your own business.

Connectors also rot. The tool changes its export format, someone reorganises the shared folder, an API gets deprecated. Every connector is a maintenance commitment, so every one should earn its place by serving a named workflow. Access you cannot justify is access that will fail at the worst moment.

When this block fails you get one of two problems. Too few connectors and the agent invents facts about your own clients, because it has no way to check. Too many, with write access granted early to save time, and one day it double-books a client or moves a file someone needed. Both failures look like the model being unreliable. They are actually a missing or careless connector layer.

A skill is a documented way to do a job that recurs. Not a prompt. A prompt gets you one output, once. A skill says: when this situation comes up, follow these steps, in this tone, escalate here, and this is what finished looks like.

Skills are where individual AI use turns into team capability. Someone on the team probably keeps asking the model to check client briefs before quoting, and doing it well, with a routine that lives entirely in their chat history. Write that routine down once as a skill and it becomes an asset anyone can run. The habit stops dying with the person who invented it.

A complete skill has six parts. The trigger, what kicks it off. The inputs, what it needs to be given. The steps, in order, including the checks. The tone, because a handoff email and a red flag read differently. The escalation, which cases go to a human. And the definition of done, what the output actually is. Half a skill teaches the model to guess, which is worse than no skill, because it lends the guess the authority of a procedure.

The skills I use personally cover the work I repeated five times a week: drafting client emails in my own voice, reviewing quote scope against the rules that have burned us before, preparing a morning brief of what actually matters today. Each one replaced manual work with a documented version of how I already did it. None of them required new tools. They required writing down what good looked like.

A skill is an operational document, so it needs what any operational document needs: an owner, a review cadence and version history. A skill that contradicts current practice is a liability, because old rules with the authority of documentation get followed longer than old rules without it. Review them when the process changes, not on a calendar nobody obeys.

When this block fails, the symptom is inconsistency. The output is sometimes good, sometimes not, and nobody can say why, because the difference lives in whoever prompted it that day. The other failure is cultural: the team treats prompts as private advantage, nothing spreads, and every person rebuilds the same routine alone.

The last block is a role. An agent is a named persona with an operating style and, above all, boundaries: what it may do on its own, what it must ask about, and what it never decides.

Two parts matter. First the persona. A quote reviewer behaves differently from a researcher, even on the same model with the same knowledge. The persona frames what the model pays attention to, what it flags, what it ignores. Second, the boundaries. It may draft a client email. It must ask before anything is sent. It never quotes a price alone. Written down, agreed, enforced.

Boundaries are not bureaucracy. They are what makes delegation comfortable, and comfort is what makes people actually use the system. A team that trusts an assistant to stay in its lane gives it real work. A team that has seen it overstep once quietly stops asking it for anything. The boundary list is the trust contract.

The efficient shape here is one brain with several agents on top, rather than a pile of separate setups. The same knowledge base, the same connectors, and a set of modes: digital lead, account manager, researcher, each with its own persona and its own boundary list. Seven standalone assistants with seven configs means seven things to maintain and drift out of sync. One brain with switchable roles means the knowledge and the connectors stay current in one place, and the roles stay cheap to change.

When this block fails, the failure is loud and eventually public. The agent without boundaries works fine for months, which teaches everyone to stop watching it, until the day it confidently does something no person would have done. Read any AI incident story in the trade press and you will find this shape underneath: three competent blocks and a missing fourth.

There is a clean way to hold the framework. Knowledge and connectors are what the system has: one static, one live. Skills and agents are how the system behaves: one defines the work, the other defines the role.

The blocks multiply rather than add. Skills without knowledge run the right steps in the wrong context. Connectors without agents have access but no judgment about what to do with it. Knowledge without skills is a library nobody reads. A strong setup is strong in all four, and a disappointing setup is almost always strong in exactly one.

Once you can see the blocks, you can map any AI tool onto them in minutes. A shared chat subscription gives you a sliver of knowledge through custom instructions, no connectors, prompts instead of skills and no agents. That is why it stalls. AWS Bedrock AgentCore gives you the agent as model and prompt, memory as knowledge, markdown in S3 as skills and the gateway as connectors, at enterprise price and complexity. Same four blocks, different packaging. The question to ask any vendor is simply which blocks they give you and which ones you still have to build yourself.

The framework earns its keep as a diagnostic. When a team tells me their AI setup disappoints, I ask five questions, one per block plus one for adoption, and the answer is usually obvious within ten minutes.

“It doesn't really get us.” Knowledge. The system has no standing context or what it has is stale. Fix what it knows before touching anything else.

“It makes things up about our clients.” Connectors. The model cannot check, so it guesses. Hallucination about your own business is usually a missing connector wearing a disguise.

“The output is fine but inconsistent.” Skills. The quality lives in whoever prompted it that day. Document the routine once and the variance disappears.

“It did something we didn't want.” Agents, specifically boundaries. Either the boundary list does not exist or nobody enforced it. This one is worth fixing immediately, because it is the failure that costs trust.

“Honestly, nobody uses it.” Usually no skill serves a repeated job, so there is no reason to return, or the boundaries are unclear, so nobody trusts it enough to build a habit. Adoption problems are almost never model problems.

For a team, build knowledge first. Shared context about who you are and how you work is the foundation every other block sits on, and writing it down is half the value, because the team has often never written it down before. Then a light persona, then one skill for one repeated job, then connectors only as that skill demands them.

For yourself, the order flips. Start with the persona and its boundaries, because that is what makes the assistant usable at all. Then skills, as your own routines become obvious. Knowledge accumulates naturally. Connectors come last and stay minimal, because a personal setup with fewer moving parts survives your busy weeks.

But the honest answer to sequencing is none of them, first. Start with the workflow. Pick a job that repeats, map its trigger, inputs, outputs and review step, and get one loop working manually with a plain chat if that is what it takes. The four blocks are how you systematise a loop that already works. They are not a substitute for knowing what the job is.

Models change every quarter, and most AI advice has a shelf life to match. The four blocks do not, because they are decisions about your work, not about the model.

When a smarter model ships, you swap the engine and keep the decisions. The knowledge base, the connector permissions, the skills, the boundary lists: all of it carries over untouched. The source ladder on that proposal agent does not care which model runs it. A better model just makes the same four decisions execute better.

That is also the investment case. Time spent tuning a single chat thread does not travel. Time spent on the four blocks compounds, because every hour of it is an hour about how your business works, which was worth writing down before AI existed.

So the next time someone tells you their team uses AI, ask the four questions. What does it know? What can it reach? What does it do repeatedly? Who does it act like? Four good answers and you are looking at a capability. Anything less and you are looking at a subscription.