Solution Design & Architecture

Solution Design & Architecture is the heaviest single slice of CCAR-P, and it is graded from the sponsor's chair rather than the engineer's. Items hand you a business situation — a claims backlog, a support queue, a research team drowning in PDFs — and ask which architecture is right-sized for it.

The trap is technology-first reasoning. Candidates reach for a multi-agent system because the scenario sounds complex, when a single structured prompt or a three-step deterministic workflow would move the same metric at a fraction of the cost, latency and failure surface. Distractors are rarely wrong technology; they are correct technology aimed at the wrong problem size, or an elegant design that quietly violates one stated constraint.

The idea that unlocks the domain is escalation. Start at the cheapest pattern that could work and climb only when a named constraint forces you: prompt, prompt chain, routing, orchestrator-worker, autonomous agent, multi-agent. Every rung buys capability and pays in tokens, latency and non-determinism. Be able to say what the rung bought, in the sponsor's units.

• Size to the problem, not the technology · the right answer is the cheapest pattern that clears the sponsor's metric.

• Escalation ladder: single prompt → prompt chain → routing → parallelization → orchestrator-worker → autonomous agent → multi-agent. Climb only under constraint pressure.

• Workflow when the steps are known before runtime and the path is stable. Agent when the path is discovered at runtime and the step count is unpredictable.

• Workflows buy determinism, stage-level tests and predictable cost. Agents buy adaptability and pay in tokens, latency and variance.

• Multi-agent earns its cost on three tests only: subtasks are genuinely parallel, per-subtask context exceeds one window, or specialist roles need isolated instructions and tools. Otherwise give one agent more tools.

• Value pillars: cost avoidance, revenue lift, cycle-time reduction, risk and compliance reduction, quality and consistency. Pick one primary pillar per solution and instrument it.

• Quote value as baseline → target → measurement method, in the sponsor's units. Handle time 14 min to 9 min on the existing sample beats "improves efficiency".

• Build vs buy: buy the undifferentiated layer — connectors, vector store, observability, eval tooling. Build only what encodes proprietary process, data or judgment.

• Human-in-the-loop is a design axis, not a safety bolt-on. Put approval where an action is irreversible or externally visible — money moved, message sent, record deleted.

• Every autonomous component needs three bounds: max iterations, a cost ceiling, and a defined escalation path to a human.

• Define pilot exit criteria before the pilot: the baseline, the threshold, and the decision the sponsor makes when it is met or missed.

• Phase the roadmap by risk, not by capability — ship the assisted version, prove the metric, then widen autonomy.

• Agent-washing · calling a fixed three-step pipeline an agent. If you can draw the flowchart in advance, it is a workflow.

• Multi-agent on a single-context task: duplicated work, multiplied tokens, handoff loss, and no capability gain.

• Unbounded autonomy — no step budget, no cost cap, no stop condition. The scenario that says "the agent kept researching" is a bounds failure, not a model failure.

• Solving a data problem with architecture. If answers depend on private or fresh knowledge, the fix is retrieval or a tool, not more agents and not a bigger model.

• Optimizing demo accuracy over unit economics. Sponsors buy cost per resolved case, not benchmark scores.

• No baseline captured before launch · value becomes unprovable and the project dies at renewal.

• Pilot with no path to production: no eval set, no owner, no observability, no rollback.

• Ignoring the human line in TCO — review time, exception handling and retraining are real costs of a low-autonomy design.

• Treating build-vs-buy as permanent. The call is time-boxed and revisited as the platform layer commoditizes.

• Designing for peak complexity instead of the volume case — most traffic is the easy path; route it cheaply and reserve depth for the tail.

• Typical item shape: a scenario plus hard constraints (latency SLA, data residency, budget, audit trail) where the constraint, not the task, selects the architecture. Read constraints first.

• Elimination order: drop options that violate a stated constraint, then drop the over-sized ones, then compare what is left on cost and simplicity.

SCOPE — size the solution before you design it.

• S · Sponsor's metric — name the business outcome, its baseline number, and who owns it.

• C · Constraints — latency, cost ceiling, data residency, audit trail, autonomy tolerance, incumbent stack.

• O · Options — build, buy or extend; the cheapest path that clears the bar wins.

• P · Pattern — prompt, chain, routing, orchestrator-worker, agent, multi-agent; stop at the first that satisfies S under C.

• E · Evidence — eval set, pilot thresholds and the instrumentation that proves the metric actually moved.

Use it whenever a scenario offers a business problem and four plausible architectures: score every option against S and C before you compare designs.