HomeAI Agency AcademyLesson 31
Module 08 · Lesson 31

Run discovery that produces an architecture

Use discovery to understand the current workflow, decision rights, systems, risks, and measurement before proposing a build.

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 run a discovery conversation that results in an implementable architecture rather than a generic wish list.

Why this matters

Good agent work is useful before it is impressive.

A client may arrive asking for ‘an AI assistant.’ Discovery has to uncover the real workflow, what people are allowed to decide, where data lives, what cannot go wrong, and how a pilot will be judged.

Field note 31

Make the relationship visible.

AI AGENTS · FIELD NOTE 31Current work → constraints → design → pilotTHE DISCOVERY01Observe02Map decisions03Identify risk04Agree pilotOriginal visual framework for Run discovery that produces an architecture.AI AGENTS · FIELD NOTE 31Current work → constraints → design → pilot01Observe02Map decisions03Identify risk04Agree pilot
Use this framework to make run discovery that produces an architecture visible before you build.
Core concepts

The language that keeps the work clear.

Workflow evidenceA real example, screenshot, record, or observation of how work moves today.
Decision rightWho can approve a change, answer a sensitive question, or resolve an exception.
ConstraintA technical, operational, policy, budget, or change-management fact that shapes the design.
Pilot hypothesisA small, measurable claim about a controlled workflow change.
The practical method

Work through the decision in order.

Ask for a recent example

Start with one real request from arrival to outcome; avoid designing from aspirations alone.

Map systems and owners

Identify authoritative records, integrations, decision makers, frontline operators, and policy owners.

Surface risk early

Ask what would make the project unacceptable: wrong action, privacy, reputation, cost, customer confusion, or staff adoption.

End with a design decision

Summarize the candidate workflow, pilot boundary, client inputs, proof measures, and unanswered questions.

Worked example

A realistic, bounded implementation.

A logistics company asks for an agent to manage delivery exceptions. Discovery traces a late-delivery case and shows that drivers, dispatch, and customer service use different tools and have different authority.

The first architecture does not promise autonomous rescheduling. It reads the tracked event, drafts an approved customer update, creates an exception task for dispatch, and sends only after the owner approves the content.

The pilot covers one route type for two weeks. The team measures response time, correction rate, and unresolved exceptions before suggesting any wider rollout.

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.

Recent case: [summary]. Authoritative systems: [list]. Decision owners: [roles]. Unacceptable failure: [risk]. Pilot workflow: [boundary]. Open questions: [list].
Spacebrain implementation

Put the operating system around the agent.

Use forms, CRM notes, call records, workflow maps, tasks, and client workspaces to keep discovery evidence, owners, and decisions connected to the proposed implementation.

Practice

Before you move on

  • Run a discovery interview around one recent case.
  • Write the system map and decision rights before naming a tool.
  • End with one pilot hypothesis and three unknowns.
  • Discovery used real evidence.
  • Operators and policy owners are included.
  • Risks are named before a proposal is written.
  • The result is a bounded pilot, not a vague architecture.

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 →