What you will learn
System boundaries, Build vs buy, Hosting constraints, Failure modes, Decision records.
Engineering the capability
Architecture starts with the customer’s operating constraints: existing systems, identity, data location, network access, support capacity, and deployment process. A technically elegant stack can be unsuitable if the receiving team cannot maintain it.
Compare a simple baseline with the proposed AI approach. State which components are owned by the customer, your team, or a service provider. Draw data flows and trust boundaries rather than only boxes. Every boundary should identify data, identity, and failure behavior.
Use decision records to capture alternatives, evidence, and conditions for reconsideration. Avoid adding an orchestration framework, vector database, or agent layer merely because it is common. Explain the requirement each component satisfies and what complexity it introduces.
Worked case
A customer already has searchable, permission-aware document storage. Copying all documents into a new vector index creates synchronization and access-control work. Querying the existing system may meet the pilot’s needs. Introduce another index only if retrieval experiments show a material gap that justifies operating it.
Put it into practice
Continue with the next lab: defend two solution options. Build the artifact, record the failure cases, and explain the tradeoff before moving on.