What an AI Architect Actually Does

Every post in this series so far has covered one component of an agent stack — a skill, a harness, a hook, a loop, a system prompt. Read them in order and a pattern shows up that none of them names directly: each of those components has to be chosen, and the choices have to fit together, or the org ends up with ten well-engineered pieces that don't add up to one working system. Somebody decides which model handles which class of task. Somebody decides what the harness permits by default. Somebody decides which skills get built, which get retired, and how a change to any of them gets checked before it ships to everyone who uses it. Once an organization has more than one team building on agents, those decisions stop being individual taste and start being a job.

That job doesn't always come with a title. At most companies right now it's a hat one senior engineer wears on top of their actual role, picked up because they were the first person who cared enough to write the shared CLAUDE.md or the firstSKILL.md anyone else copied. Whether or not the title exists, the function does: someone is the AI architect— the person who owns the agent stack as a system, not just the parts they personally built. This post is about what that function actually covers, where it tends to sit inside an org, what the industry outside this series says about it, and what it looks like to do it well or badly.

The role, defined by what suddenly needs one owner

Picture an org with three product teams that each started using Claude Code independently, six months apart, with no coordination. Team A pins an older model checkpoint because a prompt tuned against it stopped working after an upgrade. Team B lets everything auto-upgrade and has no idea a recent model change silently altered how their skills get triggered. Team C wrote a skill for reviewing database migrations that's quietly excellent, but nobody on Team A or B knows it exists, so they keep reinventing worse versions of it. Security asks all three teams, separately, what an agent is and isn't allowed to touch, and gets three different answers. Finance asks why the optimizer bill tripled last month and nobody can point to a number that explains it.

None of that is any single engineer's fault. Each team solved its own problem reasonably well in isolation. What's missing is a person who looks at all three teams' decisions together and asks whether they cohere — the same model portfolio, the same baseline permissions, a shared skill library instead of three reinventions, one number for what this actually costs. That's the job. The honest one-line description: an AI architect is a solution architect applied to a stack whose core component happens to be probabilistic. The scope of the job — own the decisions that cross team boundaries, keep the whole system coherent, be the person security and finance can actually get a straight answer from — is identical to solution architecture anywhere else. The twist is that the central component doesn't behave the same way twice, which is exactly why evals, budgets, and guardrails end up mattering more here than they would around a deterministic service.

What the industry says the role is

That definition holds up as first-principles reasoning, but it's worth checking against what the industry has published, because 2026 job descriptions sharpen it in a way the "hat someone wears" framing understates. Gartner has published research establishing the role explicitly, and its framing lands where the scenario above points: an AI architect sits inside enterprise architecture as the person who helps AI initiatives clear a specific failure mode — stalling on poor architectural choices and a lack of production scalability. The job, in Gartner's own phrasing, is to operationalize and scale AI, not train the models underneath it.

Real 2026 postings sharpen that toward agents specifically. Deloitte Canada's "AI Solutions Architect – Generative AI" listing asks candidates to "define architectures leveraging LLMs, RAG, agents, and orchestration frameworks" and "establish patterns for prompt management, model evaluation, and versioning," with explicit knowledge of "model evaluation frameworks, benchmarking, and drift monitoring" listed as a qualification — a direct restatement of the artifact map below, written by someone already living inside it. Accenture's "Advanced AI Architect" posting asks for the same shape at enterprise scale, delivering "full-stack AI architecture" using "AI Agents, Generative AI, Foundation Models, and Knowledge & Data Engineering" together, with governance and security named as part of the job rather than bolted on after. The clearest sign the agent-era version of this role is being formalized, not improvised team by team, is that Microsoft now sells a certification for it — "Microsoft Certified: Agentic AI Business Solutions Architect" — covering architecture strategies for integrating AI and agents and, tellingly, securing AI models and data workflows against risks like prompt manipulation. AWS's own Well-Architected Machine Learning Lens makes the related point from the infrastructure side, naming its audience as "CTOs, architects, developers, data scientists, and ML engineers" together — the same blended audience Gartner describes.

The artifact map: six things one role owns as a system

Six concrete artifact groups make up the job. None of them is new — this series has already covered the mechanics behind most of them individually. What's new is treating them as one portfolio with one owner, instead of six unrelated decisions made by whoever happened to be in the room.

• Model portfolio. Which model handles which task tier, whether a given team pins a checkpoint or rides auto-upgrades, and how a model version bump gets rolled out rather than silently applied everywhere at once. Understanding what actually changes between model tiers — the subject of this series' system-prompt teardowns — is a direct input to this decision, not a curiosity to read once and forget.
• Harness configuration. The permission baseline, the hooks, the sandboxing rules — everything the harness post covers, except now scoped to an org instead of one project, with the base-plus-overrides shape that lets one team's legitimate need for broader access not become everyone's default.
• Skill and command library. What gets built once and shared, versus rebuilt three times badly. Skills and slash commands are the mechanics; curation — deciding what belongs in the shared library, what stays local, and what gets retired because nothing triggers it anymore — is the part that has no dedicated post because it's a judgment call, not a mechanism.
• Eval suites and regression gates. The check that runs before a model bump, a prompt edit, or a skill change ships to everyone who depends on it. This is the artifact with the highest ratio of leverage to effort, and it's the one most orgs skip until the first bad rollout forces the issue.
• Cost and latency budgets. A number per team, per task class, that turns "the optimizer bill tripled" from a mystery into a line item someone signed off on. This is where fan-out decisions and unattended loops stop being purely technical calls and start being budget calls.
• Guardrails and audit. What's enforced, not just requested — the control layer from the harness post, plus deterministic hooks wherever a rule actually matters, plus a log that answers "what did the agent do and why" after the fact instead of only in the moment.

The reason to draw this as one map instead of six separate checklists is that the artifacts interact. A generous harness without an eval gate on the skills it loads is a faster way to ship a regression, not a more capable agent. A rich skill library with no cost budget is how one team's helpful automation becomes everyone's unexplained bill. Owning all six together is what makes the map more than the sum of its parts — and it's also exactly the part of the job that's easy to skip when everyone involved is heads-down on their own piece.

The agent labs converge on similar advice. Anthropic's guide to building agents draws a sharp line between workflows (predefined code paths) and agents (which direct their own process and tool use), recommending sandboxed testing and real guardrails before granting the latter autonomy — and its multi-agent writeup supplies the cost number behind the model-portfolio decision above: fanning work out across subagents used roughly 15 times the tokens of a single call, with token usage alone explaining about 80% of the performance variance measured. OpenAI's guide adds the same caution on guardrails — layer model-based classifiers with plain rules like regex and input-length limits, rather than trusting one system prompt alone — and regulation makes none of this optional: NIST's AI Risk Management Framework assigns the architect its "Map" and design-side "Manage" functions, and the EU AI Act requires design-time risk management (Article 9), automatic logging (Article 12), and built-in human oversight (Article 14) for anything high-risk — requirements landing on whoever owns the guardrails bullet above.

Where the role sits

There isn't one right org chart position for this, but there are two shapes that show up repeatedly, and they trade off in predictable ways — the platform-team pattern and the embedded-architect pattern, covered in more depth in the trade-offs section below. What matters more than which shape an org picks is who the role actually serves: the engineers using the model portfolio, the harness, and the skill library every day, not an abstract notion of "AI strategy." A stack that's elegant on a slide and slows every engineer down on every task has failed at the only thing that matters.

The role also sits at a genuine interface with three groups that don't normally coordinate with engineering this closely. Security wants a straight answer about what an agent is permitted to touch and how that's enforced, not requested. Compliance wants to know what's logged and for how long. Product wants to know what an agent-assisted workflow can reliably do today versus what's still a demo. The AI architect is usually the only person who can answer all three without guessing, because it's the same artifact map each group is asking about from a different angle.

This isn't a preference this post invented — it matches published doctrine. Patrick Debois, who coined the term DevOps, argues any serious generative-AI initiative deserves a dedicated platform team, and splits that team's job into three pillars that map almost exactly onto the artifact groups above: platform (model access, vector databases, agent infrastructure), enablement (sandboxes, testing support for output that isn't deterministic), and governance (data-protection training, tracking emerging AI legislation). Team Topologies reaches a compatible conclusion — which team type should own this depends on the goal, stream-aligned for shipping features fast versus enabling for clearing adoption barriers org-wide — and its own guidance is that "the best approach may combine both," the platform-plus-embedded hybrid the diagram further down is trying to draw.

A typical week

The job reads as abstract until you look at what actually fills a calendar. A representative week looks less like "strategy" and more like a backlog of small, concrete decisions:

• Reviewing eval regressions after a model provider ships a version bump, and deciding whether the org rides it or pins the previous checkpoint for the teams whose prompts were tuned against it.
• Pruning a skill from the shared library because the trigger telemetry shows it hasn't fired in six weeks — not because it's wrong, but because an unused skill is still a line in every task's frontmatter scan.
• Tightening a hook after a near-miss — an agent that got closer to running a destructive command than anyone was comfortable with — and deciding whether the fix belongs in a deny rule, a hook, or both.
• Negotiating a token budget with a team that wants to fan a task out across four subagents when a single agent with a narrower scope would do the same job for a quarter of the cost.
• Deciding, for a brand-new workflow someone just proposed, whether it needs one agent or several — the actual decision covered in the multi-agent post, now made against a real budget instead of an abstract "more agents seems more powerful" instinct.

Laid out across the five days it actually happened on, the shape of the job is easier to see than any bullet list makes it look:

None of that is glamorous, and none of it requires being the best prompt engineer in the building — it requires being willing to say no to a convenient local shortcut because it breaks something for a team three desks over.

The road into the role

If the job function is the "hat" this post keeps describing, the honest question is where someone picks it up. Coursera and Robert Half both converge on engineer-first: a background in AI or ML engineering, typically five-plus years, is the normal on-ramp, not a dedicated architect track someone starts in year one — Robert Half calls "prior experience as an AI engineer" "highly valued" for the title. The certification landscape is shifting to match: AWS is retiring its Machine Learning – Specialty exam on March 31, 2026, for the newer ML Engineer – Associate path, with architecture credentials like Microsoft's agentic-AI certification layered on top.

Look for a dedicated "AI architect" roadmap and you'll find none: roadmap.sh publishes an AI Engineer roadmap and a separate AI Agents roadmap, but nothing under the architect title — the honest read is that the path is assembled from two or three adjacent roadmaps plus a few years of fixing what they didn't cover, not that the role doesn't exist. The money is real: Glassdoor puts the average salary at $189,589 in the US; Robert Half's 2026 guide gives $142,750 to $196,750 by seniority, comfortably above senior-engineer pay. But LinkedIn's 2026 "Jobs on the Rise" list doesn't carry "AI architect" as a title, while "AI engineer" sits at number one — the most honest data point here. The function is growing fast; it's just showing up under adjacent titles first, the way the job often starts as a hat before anyone names it a role.

That's the honest shape of the road in: nobody teaches this role end to end, so it gets assembled out of whichever adjacent job someone already had when the org needed a system owner.

Anti-patterns to avoid

• Treating the six artifacts as independent. Tuning the model portfolio without touching the eval suite, or loosening the harness without revisiting the cost budget, treats a system as a pile of parts. Every change to one artifact is worth a five-minute check against the other five before it ships.
• Confusing "I built this" with "I own this." Building the first skill or the first harness config is how the role usually starts, but ownership means maintaining, curating, and eventually deprecating things other people built too — not defending your own original version of everything against every proposed change.
• Optimizing the artifact map for the architect's own workflow. A permission baseline or skill library tuned to how the one person who wrote it works, rather than how the fifty engineers who use it work, is optimizing the wrong variable. Ask the people using the stack daily what's slowing them down before assuming the map is already right.
• Writing the strategy doc before writing the eval suite. A polished governance document with no regression check behind it is a promise nobody's holding the system to. Build the gate first; write about it after it's already catching something.

Worked example: designing the agent stack for a 40-person product org

Abstractions are easiest to trust once you've watched them get applied to something concrete. Take a 40-person product organization — three engineering teams, one security function, no existing agent governance — standing up its first shared agent stack from a blank slate. Here's the sequence, end to end.

Step 1: pick model tiers per task class, not per team

The first mistake to avoid is letting each team pick its own model by preference. Instead, define task classes and pin a tier to each one, so the choice tracks the work instead of the team doing it:

• Lint and format checks ride the fast, cheap tier, auto-upgrading with no eval gate needed — a regression here is annoying, not dangerous.
• Day-to-day PR review runs on a mid tier that auto-upgrades, but only behind the eval gate from step 4.
• Architecture review and anything security-sensitive runs on the frontier tier, pinned to a checkpoint, upgraded manually after a full eval suite run.
• Unattended overnight loops — the pattern the loop engineering post covers — run on a mid tier that's pinned, since a version bump nobody's watching is exactly the wrong moment to auto-upgrade.

The shape underneath all four: cheap work rides upgrades freely; a silently changed model running unattended overnight is a worse failure than a checkpoint everyone knows is a few weeks stale.

Step 2: define the harness permission baseline

Next, a single default-deny baseline every team starts from, with specific, reviewed exceptions layered on top per project — the same base-plus-overrides shape the harness post recommends for a single project, now applied org-wide. It allows read, grep, and glob with no prompt, since none of those can change anything; asks before every edit, write, or git push, so a human sees the diff before it lands; and hard-denies the handful of commands too dangerous to approve inline in the moment — a Kubernetes rollout or delete, a Terraform apply, an rm -rf — with a hook logging every Bash invocation as it happens, not after the fact. Every team can widen this for a genuinely justified reason — a deploy tool for the team that owns the deploy pipeline, say — but the widening is a reviewed, logged exception to a shared baseline, not each team's own from-scratch guess at what's safe.

Step 3: seed the first three shared skills

Rather than waiting for teams to organically converge on shared tooling, the architect seeds a small, deliberately narrow starting library — three skills chosen because all three teams already need them, not because they're impressive. The first is the migration-review skill from earlier in this series, reused unmodified because it was already built right the first time. The second, new one covers a public API contract: it triggers on any pull request touching a file under api/schemas/ or openapi/, diffs it against the previous committed version, checks the org's versioning policy if that diff reports a breaking change, then summarizes the result against a fixed review template so every contract review reads the same way regardless of who triggered it. The third is a short incident-triage skill, scoped like the on-call agent from the harness post — read-only, no deploy access, draft a PR instead of acting directly. Three narrow skills already useful to more than one team beat twenty nobody asked for.

Step 4: set up an eval gate for prompt and skill changes

This is the artifact most orgs skip, and the one that pays for itself fastest. Every change to a shared skill, prompt, or the model portfolio runs against a fixed set of regression cases before it's allowed to ship to the shared library. For the migration-review skill, that golden set is a dozen or so real, previously-seen migration diffs, each a case with a specific expected verdict — a not-null column with no default and no down migration should fail reversibility; a nullable column with a real down migration should pass; a CREATE INDEX CONCURRENTLY should pass the lock-duration check specifically. Each case carries a minimum score to clear, not just a pass or fail, because "close to right" and "confidently wrong" are different failures deserving different responses, and any case below its threshold blocks the merge outright — the same mechanism a golden test suite gives regular code, applied to something that doesn't behave the same way twice.

Step 5: plan rollout and the feedback loop

The gate isn't the end of the story. Rollout goes to one team first, with a week of real usage and a short survey before the change ships org-wide — the same caution the model portfolio applies to a version bump, now applied to the architect's own changes too. Feedback comes back through one channel every time: a shared issue tracker label, reviewed weekly, not a scatter of Slack DMs to remember to check.

How this fails in practice

Most of the ways this role goes wrong aren't exotic — they show up as one of a handful of recognizable shapes, almost always traceable to one of the six artifacts being neglected or one person becoming a single point of failure.

Every model bump becomes a surprise regression

Symptom: a routine provider-side model update goes out, and three days later a team notices their skill stopped triggering reliably, or a review that used to catch a class of bug stopped catching it. Cause: there's no eval gate standing between "a new model version exists" and "everyone is now running on it," so the org finds out from a user complaint instead of a failed check. Fix: the eval suite from the worked example above, wired to run automatically the moment a pinned tier is up for review — cheap tiers auto-upgrade freely, but nothing pinned moves without the gate passing first.

The architect becomes the bottleneck, and shadow prompts appear

Symptom: every prompt or skill change routes through one person, that person is backlogged two weeks deep, and engineers start keeping their own local, unreviewed versions of shared skills just to move faster. Cause: the role got defined as "approves every change" instead of "owns the gate every change has to pass" — a human reviewing every diff doesn't scale past a handful of teams; an eval suite does. Fix: shift from manual approval to automated gate plus spot review, freeing the architect to review the cases themselves, not every diff that runs against them.

Guardrails get bolted on after an incident, and they're blunt

Symptom: after a near-miss, a new deny rule ships that blocks the dangerous action — and also blocks three legitimate workflows that used a similar-looking command, and engineers start routing around it within a week. Cause: a guardrail written under incident pressure optimizes for "never let this specific bad thing happen again," not for "constrain the actual risk without collateral damage" — the coarse-gate failure the harness post already named. Fix: treat a post-incident guardrail as a first draft. Give it a week of real usage, check what legitimate work it's blocking, and narrow it to the specific risk instead of leaving the blunt version in place because it technically works.

The library grows to a hundred skills nobody can find

Symptom: the shared library has ballooned over a year, most skills were built for one team's one-off need, and engineers report it's faster to write a new skill than to find out whether an existing one already covers their case. Cause: the library grew by addition with no pruning process, so the discovery cost — every installed skill's frontmatter gets scanned on every task, as the skills post covered — keeps climbing while the fraction that ever actually triggers keeps falling. Fix: track trigger telemetry per skill and review it on a cadence, the way a codebase gets a dead-code pass. A skill that hasn't fired in two months needs a better description or needs to be retired — either beats leaving it there indefinitely.

Trade-offs: what this role has to decide, over and over

Centralize the library, or federate it?

A fully centralized library — one team owns every shared skill, every team consumes — gets consistency and a single place to apply the eval gate, at the cost of a queue: nothing ships until the central team reviews it. A fully federated library — every team owns and ships its own skills with no shared review — moves fast and duplicates effort, and the discovery-cost problem above shows up twice as fast. Most orgs land somewhere in between, and the org topology underneath the library decision usually mirrors the same choice at the team level.

Neither pattern is categorically right. A central platform team suits an org where consistency across teams matters more than any single team's velocity — regulated environments, or a company small enough that one hub genuinely can keep up with three or four teams' worth of requests. Embedded architects suit an org where teams' needs have genuinely diverged enough that a shared baseline would be wrong for at least one of them, provided the embedded architects actually sync with each other — the mesh in the diagram above is doing real work, and it's the first thing that erodes when nobody's explicitly responsible for maintaining it.

Pin model versions, or ride auto-upgrades?

Pinning buys predictability at the cost of someone's attention every time an upgrade is worth taking. Auto-upgrading buys continuous improvement for free, at the cost of the occasional silent regression discovered by a user instead of a test. The worked example's answer — pin where the blast radius of a silent regression is large, auto-upgrade where it's small — isn't a universal rule, but "what does a bad surprise here actually cost us" is the right question to ask per task class, not once for the whole org.

Build the harness, or buy it?

Building in-house gets exactly the permission model and hooks a team's risk profile needs, at the cost of maintaining it. Leaning on a platform's default harness and only overriding specific pieces gets a maintained baseline for free, at the cost of whatever that default assumes about a typical team. Most orgs land on the middle: start from the default, treat every override as a deliberate, logged exception, not a from-scratch rebuild for no reason beyond not having checked what already exists.

A full-time role, or a hat someone wears?

Be honest about this one: at most organizations, it starts and stays a hat — something a senior engineer does alongside their real job, not a headcount line. That's not a failure state; the artifact map doesn't require a dedicated org chart box, only someone accountable for all six artifacts together. The signal it needs to become full-time isn't a specific team size — it's the moment the person wearing the hat can't keep up with the volume of changes without something else on their plate slipping. Refuse to formalize it past that point and the bottleneck failure mode from earlier in this post arrives on schedule.

AI architects and Noddle Deck

A persona pack is a small, pre-curated slice of exactly the artifact map above — a skill and command library someone else has already scoped, versioned, and kept from sprawling, dropped straight into whatever harness and model portfolio your org already runs. It's not a substitute for owning the six artifacts yourself, but it's a fast way to see a well-scoped library in practice, and a reasonable seed if you're standing up the first shared library from nothing, the way the worked example above did.

noddle-deck pack install developer

Every pack installs the same way regardless of tier, so trying one costs nothing beyond looking through what lands in ~/.claude/skills/ and ~/.claude/commands/ afterward — a concrete example of the library artifact from the map at the top of this post, ready to compare against whatever your org has already built.

References

Sources for the industry claims above, fetched or snippet-verified in July 2026 — treat job postings and certification pages as dated snapshots, not live feeds.

• Artificial Intelligence Architect: A Key Role to Operationalize and Scale Your AI Initiatives — Gartner
• Tool: The Emergence of AI in Enterprise Architecture Demands the Creation of an AI Architect Role — Gartner
• AI Solutions Architect – Generative AI (job posting) — Deloitte Canada
• Advanced AI Architect (job posting) — Accenture
• AI Architect — 2026 Salary Guide — Robert Half
• What Is an AI Architect? — Coursera
• Microsoft Certified: Agentic AI Business Solutions Architect — Microsoft Learn
• Machine Learning Lens — AWS Well-Architected Framework — AWS
• AWS Certified Machine Learning – Specialty — AWS
• AI Agents Roadmap — roadmap.sh
• AI Architect Salaries — Glassdoor
• LinkedIn Jobs on the Rise 2026: 25 Fastest-Growing Roles (US) — LinkedIn
• Why AI Needs a Platform Team (PlatformCon 2025) — Patrick Debois
• How Team Topologies Can Transform Generative AI Integration — Team Topologies
• Building Effective Agents — Anthropic
• How We Built Our Multi-Agent Research System — Anthropic
• A Practical Guide to Building Agents — OpenAI
• AI Risk Management Framework (AI RMF 1.0) — NIST
• EU AI Act, Article 9 — Risk Management System — EU AI Act Explorer