HomeAI Agency AcademyLesson 39
Module 10 · Lesson 39

Build a delivery team and partner network

Define roles and access so strategy, implementation, QA, support, and specialists can work without broad production permissions.

Last updated August 5, 202615–25 minutesFree AI agent course
What you will learn

Make a clear, safer operating decision.

You will be able to structure a small delivery team with clear responsibilities and controlled access instead of giving every contributor broad client authority.

Why this matters

Good agent work is useful before it is impressive.

Scaling does not mean removing accountability. More people, contractors, and partners add handoffs and permissions. A good operating model clarifies who decides, builds, tests, supports, and approves changes.

Field note 39

Make the relationship visible.

AI AGENTS · FIELD NOTE 39Strategy → build → QA → support → specialistTHE TEAM01Client owner02Implementation03Quality review04EscalationOriginal visual framework for Build a delivery team and partner network.AI AGENTS · FIELD NOTE 39Strategy → build → QA → support → specialist01Client owner02Implementation03Quality review04Escalation
Use this framework to make build a delivery team and partner network visible before you build.
Core concepts

The language that keeps the work clear.

Responsible ownerThe person accountable for the outcome of a role or client engagement.
Separation of dutiesAvoiding a situation where one person can make, approve, and hide a consequential change.
SpecialistA contributor with a defined expertise or integration responsibility, not a blanket client administrator.
RunbookA concise operating guide for recurring incidents, handoffs, reviews, and client communication.
The practical method

Work through the decision in order.

Define core roles

Name strategy or client success, implementation, quality review, support, and any domain or integration specialist.

Assign decision rights

State who may approve client policy, production change, access, incident communication, and expansion.

Scope access

Give contributors the least production access needed for their task; use review or staging where possible.

Write the handoffs

Document what each role receives, produces, escalates, and records so client context survives team growth.

Worked example

A realistic, bounded implementation.

A growing implementation partner has a strategist run discovery, a builder configure workflows, a QA reviewer run the evaluation set, and a client-success lead lead weekly reviews.

The builder cannot approve a policy-sensitive outbound message alone. A partner who works on a calendar integration receives scoped technical access, not a client-wide CRM administrator role.

When a support incident arrives, the runbook says who contains it, who tells the client, what evidence is captured, and who approves a fix. The team can grow without turning into an untraceable group chat.

Build it in practice

Use this copyable working template.

Adapt it to the client’s evidence, policy, people, and tools. Do not treat placeholders as approved instructions.

Role: [role]. Owns: [outcome]. May decide: [list]. Access needed: [scope]. Receives: [handoff]. Escalates to: [role].
Spacebrain implementation

Put the operating system around the agent.

Use client workspace roles, task assignment, approval workflows, activity logs, and team reporting to preserve ownership as the delivery team grows.

Practice

Before you move on

  • Map roles for one client delivery.
  • Find one place where the same person can create and approve a risky change.
  • Write a handoff checklist between build and QA.
  • Each role has a clear outcome.
  • Decision rights are explicit.
  • Access is scoped.
  • Runbooks cover recurring handoffs and incidents.

Build the operating layer around your agent.

Use the free Spacebrain workspace to keep contact context, handoffs, tasks, automation, and reporting together.

Start for free →