Skip to content

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.

Updated August 2026 · AI Agency Academy

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.

Core concepts

The language that keeps the work clear.

Workflow evidenceA real example, screenshot, record, or observation of how work moves today.
Saved on this device.
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.

  1. 01

    Ask for a recent example

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

  2. 02

    Map systems and owners

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

  3. 03

    Surface risk early

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

  4. 04

    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.

Put the learning to work

Build an AI service people can trust.

Create a free Spacebrain account and use the operating layer around your AI service.

Start free trial