Produce the discovery architecture
You will be able to run a discovery conversation that results in an implementable architecture rather than a generic wish list.
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.
Turn current work, constraints, decisions, and risk into a pilot design
The language that keeps the work clear.
How to produce the discovery architecture
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 case: run discovery that produces an architecture
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.
Complete the working artifact
Paid discovery should end in a decision.
Discovery is a useful deliverable when it lets the client choose whether and how to proceed. It should document the current workflow, evidence, constraints, system ownership, decision rights, risks, target architecture, pilot, budget range, and unresolved questions.
- Price discovery separately from implementation.
- Do not promise a build before access and policy constraints are known.
- Give the client a usable recommendation even if you are not selected to implement it.
Sources used for this check
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.
Lesson progress
Finished this lesson?
Save your place on this device so it is easy to pick up where you left off.
Not marked complete yet.