AI Systems & Agents

How to give an AI agent team the right tools and take it live — access, workflows, and go-live

Part 4 was the guardrails. This part is the power. Tools, workflows, skills, and the moment you switch the team on.

If you are on the single-tool path, take the light version: one toolset for your one process, one simple workflow, and a basic keep-list of what stays yours. Assistant path? Limited tools per agent and a couple of recurring workflows. Team path? Full part. This is where the profiles stop being documents and start being permissions.

Two things. Give each agent the tools its lane actually needs, and nothing else. Then run one small process end to end before you scale anything — and write the procedure down as skills, so it survives contact with reality. The go-live checklist at the end is the difference between switching on a team and switching on a mess.

I have added a worksheet at the end. It is the tool access matrix, the API-versus-MCP decision sheet, the workflow, the skills register, and the go-live checklist. This article is how to fill it in without turning your agent into a god-mode liability with a chainsaw.

Tools are permissions, not toys

Every tool you give an agent expands what it can break as well as what it can finish. That is not paranoia. It is the same reason you don’t hand the apprentice the keys to the server room on day one.

A tool without a job is noise. If the lane mission doesn’t need it, keep it closed. A job without the required tools is theatre — the agent will fake progress or pester you to become the tool. And the final allow and deny lists must be written into the Agent Profile. Chat memory of “you can use GitHub” is not access control. It is a rumour with a keyboard.

Cup of tea, not the ocean — tools edition.

Open the smallest tool set that completes one real process, then add incrementally. The first process gets only the tools required end to end. No “future needs” integrations on day one. Add the next tool only after the current set ships reliably — earned access, not wishlist access. One new integration at a time, so when cost or failure spikes, you know what caused it.

Minimum viable toolset by need.

Start from the lane outputs and work backwards to tools. Files and workspace when the artefact lives in documents or code. Terminal when the agent must run commands or tests. Browser for live checks and research. GitHub for code history and reviews. Email and messaging only if the lane truly sends or triages communications. Calendar and external APIs only for concrete recurring duties, not “just in case”.

API versus MCP. Choose on purpose.

Both work. They fail differently and cost differently. A direct API or CLI is usually thinner and easier to limit to the exact endpoints you need. An MCP is a convenient bundle of tools in one connector — but the whole surface can load into agent context whether you use it or not.

The decision rule is boring, and it works: prefer the narrowest interface that does the job. Convenience is not free if it drags fifty unused tools into every run. Don’t add an MCP because it is trendy. Add it because the lane repeatedly needs that capability and you can prune it.

Tool load, context cost, and token burn.

Unused tools still tax you. Every exposed tool description consumes context — fat catalogues shrink the room for the actual task. They also increase confusion and bad tool calls. The model spends tokens browsing a drawer of odds and ends. Retries on wrong tools multiply the burn. One bloated connector can turn a cheap task into an expensive loop.

Measure cost per completed task, not “the connector worked once”. Part 1 economics still apply. Subscription and rate-limit burn is real — a bad tool load can exhaust a plan shockingly fast.

MCP hygiene: review and turn tools off inside the connector.

Installing an MCP is not the finish line. Pruning it is. Inventory every tool it exposes before giving it to an agent. Disable everything not required for the current lane — default off, not on. Prefer the read-only subset first. Open write, publish, and delete tools only when the process proves it needs them. Re-review after the first real week and turn off anything unused or noisy. If an MCP cannot be pruned to a sane subset, treat that as a product defect and switch to an API or a thinner connector.

I carry the scar from this stage. I once loaded a social media connector with a huge tool surface into an agent’s context. Useful on paper. In practice the catalogue plus confused calls plus retries burned a full subscription in a day. Not because one post is expensive. Because the load and the loops are. Evaluate connectors on tool count, prunability, and cost under failure — not on the feature demo screenshots.

What should never be automated lightly.

Some powers stay human-gated even on a team path. Production deploys and infrastructure changes. Payments, purchasing, contract sends. Secret creation and credential distribution. Mass delete and irreversible data changes. Public posts without a release gate. And anything your Part 1 process cannot explain to a five-year-old — if you cannot specify it, don’t automate it.

Lockdown design.

Deny by default, open with justification, review after incidents. Default-closed on high-blast tools. Separate “can read” from “can write, publish, deploy” — observation is safer than action. Sandbox first, production only with an explicit gate. Bind tool access to the evidence and escalation rules from Part 4 — power without proof is how accidents ship. And bind the API-versus-MCP choice and the enabled-tool subset into the profile. “We installed it” is not a permission model.

Rabbit holes, so you can walk past them:

• God-mode agents with every integration “for flexibility”. Flexibility is how blast radius and token burn hide.
• Installing multiple fat MCPs on day one. Fat tooling before a cup-of-tea end to end process works.
• Leaving every MCP tool enabled because disabling feels fussy. Fussy is cheaper than a wiped subscription.
• Re-opening production tools because one task was annoying. Temporary exceptions become permanent holes.
• Judging connectors only by happy-path demos. Failure-path retries are where the bill appears.
• Keeping allow-lists only in your head. If it is not in the profile, it will drift.

Workflows that survive contact with reality

Tools are the power. The workflow is the steering. Without it, you have a very capable agent doing whatever looked helpful at the time.

Cup of tea, not the ocean — workflow edition.

Run one thin end-to-end process before you scale lanes, tools, or autonomy. One process, one owner path, one definition of done. Prove the loop — brief, do, check, ship — and only then add the next process. Incremental autonomy. Don’t jump to hands-off team fantasies on day one. The ocean can wait. The cup teaches you the system.

Why vibes-based execution dies.

“Just build it” skips the definitions that make agents useful. No brief means no shared success measure — agents optimise for looking busy or sounding right. No slice means endless half-work. No QA hook means silent junk, and the Part 4 gates never get a natural place to fire. No explicit human/agent split means either bottleneck everything or automate the irreversible. Both fail.

The core workflow.

Keep the path boring and repeatable. A brief — problem, user outcome, scope, assumptions, success measures. A slice — small vertical pieces with acceptance checks and a usable MVP per slice. Build in the owner lane — one owner, artefact-first, evidence as they go. QA at the right tier — peer for risky steps, release for the package you open. Release only after the gate — done means openable or verified, not discussed.

Turn the workflow into skills.

A skill is a written-down procedure the agent loads when the task matches. “How we write a brief.” “How we run release QA.” The difference between an agent that knows the process and one that re-invents it every run.

The workflow is prose until it becomes skills. Write one skill per stage: the brief template, the slice rule, the QA checklist, the release gate. Then the agent loads the procedure instead of improvising it. This is also the fix for the workflow-docs-nobody-loads rabbit hole. Skills load on demand, so they are not decoration.

Skills are living files, same as the profile. When a procedure changes, the skill changes. When a skill keeps failing, the skill gets rewritten. Review them on the same cadence as the soul.

The human/agent split is a progression, not a day-one fantasy.

Trust is earned. Start around 50/50, ideally 60/40 agent/human once the first process is framed — humans still heavily steer, correct, and verify; remember the toddler with the terminal, you need to parent the agent until it’s confident and correct at the process, then you take off the training wheels. The goal over time is about 80/20 on the grind once evidence, souls, and workflows are stable. Agents carry volume. Humans keep consequence.

90/10 is not a realistic starting point. Treating it as the launch split causes fake delegation and silent failure. It may become a later aspiration for mature, low-blast processes only — never the default for irreversible work. Move the split only when proof says so: repeated clean completions, low correction rate, clear escalation behaviour. If corrections are constant, the split is too aggressive. Push work back toward the human and fix the profile before re-expanding.

What the human keeps at every stage.

Consequence stays human even when grind shifts to agents. Always human: strategy, pricing, public launch, production approval, spend, account creation, kill or pause, legal and money commitments. Early stage human-heavy: prompt shaping, acceptance judgement, tool choices, soul edits, first-publish checks. Agent-expandable later: research assembly, drafting, implementation, filing, checks, board hygiene, monitoring signals — only after the cup-of-tea loop works. Write the current split into the profiles and the board escalation rules. The percentage only matters if agents know what they may not own today.

Council and multi-model stress points.

Use heavier review only where failure is expensive. Architecture, high-stakes copy, contested QA, production approval packets — good council candidates. Not every ticket needs a committee. Councils for everything become delay machines. And cross-provider challenge beats same-model cheerleading — tie back to the Part 1 routing and the Part 4 independence rules.

Write the workflow hooks into the operating instructions.

Profiles must know where they sit in the path. When to demand a brief before starting — incomplete inputs get returned, not “handled”. When to split work into slices — refuse ocean-sized cards without decomposition. When to attach evidence and request QA — no self-serve done on gated outputs. When to stop for human decisions under the current split — escalate early with options, not after the mess. When not to add tools mid-task — integration changes are deliberate profile edits, not impulse grabs.

Amend the profile to v1.0, then go live

Part 3 left you with Agent Profile v0.1. Part 4 amended it to v0.2 with the integrity layer. This part closes it to v1.0 — ready to run. Same file. You are adding five things:

1. Final tool access. The allow/deny lists from the matrix, with human-gated tools marked. Replaces the starter guesses.
2. Integration choices. API, CLI, or MCP per capability, with the enabled MCP subset written down. The prune list is part of the profile.
3. Workflow hooks. The brief demand, the slice rule, the QA request, the human escalation points.
4. The starting split. 50/50 or 60/40, stated explicitly. Nobody pretends it is 90/10 yet.
5. The skills list. Which procedures the agent loads on demand — brief, slice, QA, release — instead of improvising.

The go-live checklist.

First run requires a deliberate ready state for one small process. Lane contract complete — mission, inputs, outputs, handoffs exist. Soul and operating instructions loaded, with the v0.2 integrity rules included. Tools concrete, MCP subsets pruned, API-versus-MCP chosen on purpose. Board states live — WIP, ready, done definitions real. Workflow written as skills — procedures load on demand, not from memory. Monitoring and alerts routed to a human channel — silence is not health without checks. First process chosen is one end-to-end cup of tea, not the ocean. Starting split stated. If any of those is missing, it is not go-live. It is a rehearsal.

After go-live: the living refine loop.

v1.0 starts operations. It does not end design. Watch real behaviour against the soul standards and the lane done-checks — production is the exam. Tweak the specific agent’s soul when tone, values, or quality bar drift. Tweak the operating instructions when procedure fails — don’t bury process fixes inside identity prose. Re-open, tighten, or prune tools only with justification and a logged change. Review token burn by task and by connector — if burn spikes, cut tool surface before buying a bigger plan. Advance the split only on evidence. Keep a short change log on every profile: date, trigger, edit, expected behaviour. And schedule the review cadence — a light regular pass plus incident-driven edits.

The system that is declared finished at launch rots immediately. Frozen souls, frozen tool lists, and frozen splits are how a working team becomes a museum piece.

Rabbit holes:

• Skipping the brief and the slices because the plan “looked solid”. Confident plans still need testable chunks.
• Starting at 90/10 because a blog said so. Fake autonomy without trust is just an unattended mess.
• Automating irreversible human calls too early. Agents should not own production, money, or public consequence before the system is proven.
• Scaling to five processes before one cup-of-tea loop is stable. Expansion hides the real failure point.
• Workflow docs that agents never load. If it is not in the profile, the board, or a skill, it is decoration.
• Continuous random fiddling with no log. Refinement without memory is just churn.

The scar I carry from this stage: I skipped the brief and the slices because the plan looked solid, then watched busy agents produce motion without a usable MVP. Weeks of activity, nothing to open. The fix was not better agents. It was a smaller first process, a definition of done that survived contact with reality, and the procedure written down as a skill instead of living in my head.

Download the Part 5 tools, workflow and go-live worksheet →

You should leave with:

1. A tool access matrix for your first process — allow, deny, human-gated
2. An API-versus-MCP decision per capability, with MCP subsets pruned
3. One workflow — brief, slice, build, QA, release
4. A starting human/agent split, stated in the profile
5. A signed go-live checklist
6. Agent Profile v1.0, ready to run
7. A skills register for the first process — one skill per workflow stage

Then do the build. This Session:

1. Write the tool allow/deny list for your first process. If a tool is not on the list, the agent does not have it.
2. Choose API or MCP for each capability. If MCP, write down the enabled subset and prune the rest.
3. Map the workflow for the first process, then write it as skills. One brief, one slice, one owner, one gate — each stage a skill the agent loads.
4. State your starting split in the profile. 50/50 or 60/40. Not 90/10.
5. Run the go-live checklist. Tick every box, or it is a rehearsal.
6. Switch the team on and watch the first end-to-end run. Then watch it again tomorrow.

That is the team live. Part 6 is what happens when it grows — adding agents and processes without breaking what already works.

If you cannot write the tool allow/deny list for your first process, stop here. You do not have a process yet. You have a plan-shaped wish. The tools will still be there when you are ready.