The Sovereign AI Agent: Production Ops in an Account You Own

Update: The Architecture Is Now Running in Production at Fine's Gallery

July 2026: The original deployment described in this article was forked into a separate, client-owned production deployment inside Fine's Gallery's AWS organization. The client deployment has since expanded into two isolated agent lanes: engineering and content, built from one codebase with separate runtimes, credentials, and Slack channels.

The agents now support production triage, draft-first CMS operations, SEO analysis, and governed social publishing. Every consequential action still requires human approval. The full Fine's Gallery AI operations case study documents the deployment boundary, operating model, and evidence from live use.

A Capable and Safe Agent to Manage Applications and Infrastructure on AWS

Integrating AI Agents into real businesses requires more than signing up for a Claude Max subscription. With frontier models becoming increasingly capable recently, it seemed like a good opportunity to develop a solution on AWS that can be used to safely develop and manage web applications and debug production issues. The video below is an example of the resulting agent doing just that.

The Agent Must be Trustable

The latest models are good, however the risk no longer lies in the possible inability of these tools to perform complex tasks competently, but rather in being able to trust such competence with access to your secure production environment and its applications, especially when real revenue or compliance concerns are involved. It would be difficult to justify deploying such an agent, however capable, without being able to guarantee its inability to autonomously perform destructive actions with the organization's resources: there have already been countless high-profile cases of rogue agents doing just this.

The solution is straightforward and follows many of the same principles that already motivate infrastructure design: least-privilege, well-defined blast radii, and clear audit trails, with one notable addition: strict human-in-the-loop guardrails that bring all critical decisions (and, importantly, responsibility) to an authorized biological operator.

The agent is incapable of making changes to the production database without documented human approval

What it Does

The agent is currently capable of debugging production issues: it pulls the logs, finds the broken deployment, and identifies exactly what changed. It watches spend, inspecting Cost Explorer and flagging anomalies. It ships software: it clones a repo, navigates the code, makes the change, generates the database migration, and opens a pull request for you to review; it is incapable of pushing to main / production. It operates production applications: the agent is capable of managing the content of a web application or CMS system via API, in a draft-first, HITL workflow. It also produces real design work, turning requests into mockups that can be reviewed in detail before any code is written.

The agent's AWS CLI access is strictly read-only, and mediated through specific, tightly scoped skills. The agent cannot execute a terraform apply command. Any infrastructure changes are submitted as draft PRs against the IaC, and implemented only in authorized CI pipelines.

The Architecture, Briefly

The shape of the system follows the same principle as everything above: the agent is given room to work and stopped at the boundary that matters.

The agent runs on the Amazon Bedrock AgentCore Runtime. Every invocation gets its own isolated microVM that is destroyed when the session ends, and the runtime has no public endpoint: it is reachable only through authenticated, signed calls. The agent itself is built on the Strands Agents SDK, which keeps the whole thing defined as code rather than configuration.

Its capabilities are organized as skills. The agent carries a short catalog and loads the full instructions for a skill only when it needs them, which keeps it fast and focused. Each skill is a self-contained unit: its own instructions, tools, and least-privilege permissions. Adding a capability means defining in code exactly what that capability is allowed to do, and nothing more. The model underneath can be any current frontier model on Bedrock, and the long-term trend seems to favor these becoming largely interchangeable in the future.

Motivation Behind Building This

This project began as an attempt to build a client-owned AI agent that businesses could deploy into their own operations. Before offering that pattern to clients, I validated it against this consulting platform and its AWS environment. That internal deployment still supports Conti Digital. Its code and operating model were then forked into the separate production deployment now running inside Fine's Gallery's AWS organization. The Fine's Gallery case study shows how the architecture was adapted into isolated engineering and content agents with human approval at every consequential boundary.