June 15, 2026

An architect, but hands-on: what an AI Solutions Architect actually does

Plenty of people ask what an “AI Solutions Architect” actually does all day. Fair question — the title shows up everywhere now and, on its own, means almost nothing.

So here’s the concrete version: the work itself, not the org chart behind it.

It starts with a workflow, not a model

The work never starts with “which model?”. It starts with a real process that is slow, expensive, or error-prone: a document that takes too long to find, a request bouncing between three systems, a decision waiting on someone who has no time right now.

The model is one of the last decisions, not the first.

Then comes the most important decision: build, buy, or integrate

Before the first line of code, the real question is: should we build this at all?

Most AI capabilities are commodities by now. The model, the platform, the infrastructure: much of it you buy. A good architect says “we’ll buy that” more often than “we’ll build that ourselves.” That’s exactly where credibility lives. Building your own model or your own foundation is almost always the expensive mistake.

So why build anything?

Because the decisive part is usually the one no vendor sells: integration into legacy systems, data boundaries, and regulated workflows. The pattern that works: buy the engine, build the integration. Buy the model and the platform, but build only the thin, differentiating layer that makes them fit.

In regulated settings, “buy” often ends right there: the finished product fails a data-residency or compliance requirement. So you build the part that can hold that boundary — and nothing more.

Drawing boundaries — especially data boundaries

In a regulated setting, this is half the work. Which data may the system see? Where may it live? Who may read the result? What gets logged? What never leaves the building?

These aren’t features you bolt on later. They’re design constraints. They often shape the architecture more than any model benchmark.

Build the proof, ship the MVP — in code

This is where the role separates from the roles above it. The architect doesn’t hand a diagram to a team and disappear. You build the proof of concept yourself, ship the first real version, stay in the code.

Big enough in thinking to see the whole system. Close enough to delivery to make it real.

Integrate with the reality that’s actually there

The demo works with clean data. Production has SSO, twenty-year-old document stores, half-documented APIs, and an operations team with strong and justified opinions.

Most of the engineering work lives here: getting the system to run in the organization that actually exists — not the organization on the slide.

Getting past the pilot

A system nobody uses is a failed system, no matter how elegantly it’s built.

The final stretch is adoption: enablement, measurement, support, and the unglamorous handover to the people who will operate it afterward. Production isn’t the demo that worked once. Production is the system still running after you’ve left the room.

Why the title confuses everyone

That’s the work. It’s hard to fill because the title sits in a cluster of roles that sound almost identical from the outside.

A friend from chemistry once put it well: in her field, everyone instantly knows whether someone does organic, inorganic, or medicinal chemistry. In IT, Enterprise Architect, Solutions Architect, AI Architect, and Staff Engineer sound like one job to outsiders.

They’re not. But the difference is situational, not a hierarchy.

An Enterprise Architect works one level up: landscape, standards, target picture, governance — exactly what you need when there’s a lot to connect and steer.

A Solutions Architect works one level closer to the concrete system: a use case is carried all the way to a running system, hands-on, close to the code. An organization that hasn’t built the system yet usually needs this second role first — but often writes the job description for the first one, or blends both and finds no one.

Both are real roles that solve different problems at different times. The mistake isn’t choosing one or the other. The mistake is not knowing which moment you’re in.

The underrated part: who actually builds it?

A vision and a deck are not a system. The honest question isn’t “how big does the team need to be,” but whether someone is actually mandated and equipped to build the system.

It starts with the architect: a hands-on architect stays close enough to delivery that the design evolves against reality. On that foundation, the base is deliberately small: a tight core of strong engineers, increasingly augmented by AI agents that take on work which used to require extra hands. The team that ships a production system gets smaller, not larger.

But the boundary where architectures actually fail is rarely headcount. It’s mandate. An architecture nobody is allowed to build and nobody is equipped for stays a diagram — no matter how many people are nominally available.

If you’re hiring

Don’t start with the job posting. Start with two questions:

1. What exactly can’t we do today? Not “we want AI,” but the concrete gap.
2. Which role closes that gap — and does the foundation for it already exist?

If the honest answer is “ideas yes, but nothing in production,” you very likely need a hands-on Solutions Architect with a small engineering core — not a strategy layer on top of an empty stack.

When that distinction is right, the title becomes secondary: a workflow turns into an architecture, and the architecture turns into a system people actually use.