Agentic PDLC for solution architects: authority and topology

In this lesson you'll learn:

• the architect's eight steps, and why P2 is the phase you deliberately stay out of;
• the four P1 decisions that make an agentic system safe: map, shape, bound and detail;
• what to record, what to leave to engineering, and where a model helps.

Sound familiar?#

• The design document specifies the model, the temperature and the framework version, and every one is wrong by the next release.
• An engineer built fifteen agents to show what the framework could do, and nobody can say why there are fifteen.
• The refund limit is in the design, the prompt and the slides, and not in the code.

The architect's job in an agentic system is less about boxes and arrows and more about where authority lives and where probability is allowed.

What changes for a solution architect?#

You stop specifying model settings and start specifying behaviours, and where the caps live. Temperature and framework versions belong to engineering and go stale; what does not go stale is which steps may be probabilistic at all, what each tool may do, and where the checks sit. Those are the decisions that make an agentic system safe.

Your eight steps#

P0 · Frame: the evidence under the product manager's verdict#

1 · Elicit. Two discovery meetings split by proximity to the work, every requirement credited to the person who raised it. SkyWays: 31 lines from six people. 2 · Constrain. Constraints sorted by type before any quality target is set, because a constraint can make a target impossible: the $400 refund rule reshaped three of nine quality targets.

P1 · Design & Spec: the phase you lead#

3 · Map every step as exact, best-guess or consequential. 4 · Shape: start with one agent and add one only on a named limit. SkyWays' fifteen agents collapsed to one agent, a fan-out tool, a function and a checker. 5 · Decide: merge the stakeholders' utility trees and write a decision record only at the sensitivity points. 6 · Bound: the authority budget before the token budget, every tool banded, every cap in a signature with tests. 7 · Detail: layered context, one server per legacy system with reads open and writes gated, and an independent checker after each expensive step. P1 Design & Spec

P2 · Build & Prove: answer, do not re-open#

In P2 you answer questions against the map; you do not re-open it. Every bolt was cut against the design as signed, so a redesign mid-build moves the ground under work already in flight. If the map is wrong, say so and re-cut in the open, rather than changing it quietly.

P3 · Run & Learn#

8 · Evolve. A bill that leaves its estimate becomes a new version of a decision record; an incident becomes a typed parameter rather than a name. The cost loop

What is yours, and what is not#

How to use a model in this role#

Use a model where the work is mechanical and checkable, nowhere near the trade-offs. It will turn two transcripts into a credited requirement register, rewrite nine adjectives as measurable scenarios, grep a repository for arithmetic hiding in prompts, and draft a tool schema from an API. It will also band a money tool as low risk because the diff is one line. Verify every band yourself.

Where you'll use it#

• At the start of P0, running the two discovery meetings and the constraint register.
• Through P1, where every decision that is expensive to reverse is yours.
• After every bill anomaly and incident, closing the loop in the design.

Why it matters#

Agentic systems fail at the seams the architect owns: a probabilistic step doing exact work, a swarm where one agent would do, a cap that lives in a prompt, a checker that grades its own work. Each is a design decision, cheap in P1 and expensive in production.

Key takeaways#

1. Specify behaviours and where the caps live, not model settings.
2. Start with one agent; add one only on a named limit, and keep checkers independent.
3. Lead P1, stay out of P2's way, and close bills and incidents back into the design.

FAQ#

What does a solution architect do in an AI agent project?#

Decides which steps may be probabilistic, how many agents the system needs, what each tool may do and where its limits are enforced, how context is layered, where independent checkers sit, and which decisions deserve a record, and turns production bills and incidents into design changes.

Should I use a multi-agent architecture?#

Start with a single agent and add another only when you can name the limit that forces it: a context that genuinely overflows, or parallel work a tool cannot express. Each added agent multiplies hand-offs; a fan-out tool usually gives the parallelism without them.

How do you design permissions for an AI agent?#

Set the authority budget before the token budget: band every tool by what it can change, from read-only to irreversible, give the agent only the tools the job needs, put every cap in the tool's signature with a test, and require a confirmation token the model cannot create for money actions.

What goes in an architecture decision record for AI systems?#

Only the decisions at genuine trade-off points, where changing the decision would change a quality target, each naming the options it rejected and why. Model settings and framework versions do not belong in one; they go stale in weeks.

Apply it in your role#

Across the enterprise. An architecture review for agents reviews three artefacts (the step map, the authority budget and the topology) rather than slides.

The ten-minute workflow. An authority budget that refuses to guess:

Here are the actions our agent can take: <list>. For each, ask me what one mistake costs and whether it
can be undone. Then propose a risk band (R1 read-only to R5 not delegated), the autonomy level, the cap,
where the cap is enforced (tool signature, identity or approval) and the test that proves it refuses.
Do not assign a band I have not given you evidence for.

Sources and credits#