There is an AI being trained right now that will, before long, do a large part of my job. Sitting in the requirements meeting. Writing down the project goals. Analysing the current systems. Proving the concept. Drafting the solution design. Possibly even coordinating the team. And it will get through a good deal of that before lunch.

I do not say that to be dramatic. I say it because I have spent fifteen years as a solutions architect, and I would rather look at the change squarely than pretend it is not coming. The interesting question is not whether capable AI changes this work. It is what the work becomes once it does.

What does not change

Start with what holds. Someone still has to decide what the business actually needs to be true — not what the statement of work says, but the real outcome. Someone still has to weigh the trade-offs that have no clean answer: the budget against the timeline, the ideal data model against the one the organisation can realistically run, the elegant design against the political reality in the room. And someone still has to be accountable when the system meets the messy edges of a real enterprise.

Those are judgement problems, not generation problems. AI is becoming extraordinary at producing options. It is not becoming accountable. That gap is where the role goes next.

Four roles around the work

I have started to think of capable AI agents as something you manage rather than something you simply use — closer to a team than a tool. And if you manage a team, four jobs appear around it. I have been calling the agents "AI minds", and the four jobs are: hire them, direct them, check them, build them.

Hire them

Someone has to decide which agents to bring onto a programme, which to keep, and which to quietly retire. That is a selection and assurance problem — understanding what each agent is genuinely good at, where it is weak, and what it costs to run. It looks a lot like the assurance reviews I already do, applied to a new kind of workforce.

Direct them

An agent with no direction produces confident, plausible work that is subtly aimed at the wrong target. Directing them is the architecture job: setting the goals, the boundaries, the escalation rules, and the shape of the orchestration so a set of narrow agents adds up to something coherent. This is the part that maps most directly onto what a solutions architect does today.

Check them

Agents drift. They go off the rails in ways that are not always obvious from the output. Checking them means building the evaluation and observability that tell you, with evidence, whether an agent is still doing what it was asked, and being willing to stop one that is not. In a regulated environment this is not optional, and it is not something you can hand to the agents themselves.

Build them

And someone still has to build the things: the agents, the orchestration, the grounding, the guardrails. The tools are changing quickly, but the discipline of designing a system that holds up in production is not going anywhere. If anything, it matters more.

Where this leaves me

I intend to work on all four. Not because the framing is clever, but because each of them is real work that an enterprise will need done, and none of them is the work an agent can take ownership of. The craft moves up a level: from producing the design to deciding which designs are worth trusting, and proving it.

That is the version of the future I see for this role. Not a job disappearing, but a job changing shape: towards judgement, accountability and assurance, and away from generation. It is a change worth getting ahead of rather than bracing against.

This is the first in a short series on how agentic AI changes the practice of solution architecture. If it is the kind of thing you are weighing on your own programme, I am always glad to talk it through.