Business Discovery, Requirements, and SLAs
The first architecture decision is deciding what problem you are actually responsible for solving. Convert a broad AI request into a measurable problem statement. Separate functional, quality, infrastructure, safety, and lifecycle requirements. Define success metrics, service-level objectives, and escalation boundaries. Identify assumptions that need evidence before architecture begins. Produce a discovery brief that technical and business stakeholders can approve. A support director asks for an agent that resolves every ticket automatically. The request sounds specific. It is not. You do not know which ticket classes are in scope, what resolution means, which systems the agent can change, how much financial authority it has, what latency users tolerate, or which actions require a person. You also do not know whether the real problem is response time, inconsistent policy application, backlog, cost, or customer satisfaction. If you begin with a model and tool list, you will optimize an assumption. A technically impressive system can still fail because it improved the wrong measure, automated a forbidden step, or moved work from agents to reviewers without reducing total effort. Professional architecture begins with discovery. The exam tests whether you can translate business intent into a solution and defend the tradeoffs. In practice, this skill prevents months of rework. Rewrite the request as a decision with an owner, evidence, and consequence. Weak problem statement: Decision-shaped…
Business Discovery, Requirements, and SLAs: The first architecture decision is deciding what problem you are actually responsible for solving.
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.