Fine's Gallery: AI Operations Agents for Real Work
Engineering, content, and sales support agents provide human-in-the-loop management of software delivery and AWS operations, CMS content and social publishing, and the commercial back office: call briefings, draft invoices, and mailbox replies.
What began as a single AI operations agent inside Fine's Gallery's AWS organization is now three: an engineering agent, a content agent, and a sales support agent, built from one codebase but isolated down to their runtimes, credentials, and Slack channels. The sales agent works the commercial back office: it reads the company's document archive, briefs staff before customer calls, drafts invoices and replies, and requests payments through the platform's own issuing flow. Staff can now talk to the agents literally: a voice memo dropped in Slack is transcribed server-side and handled like any typed request. Every consequential action still stops at a human approval.
Key Results
Deployment boundary
Dedicated client environment
Operational capability
Operations, content, engineering, and sales
High-impact actions
Human-approved
Production proof
From a Slack message to a live production feature
A 63-second silent walkthrough of a real production change: repository inspection, visual mockups, a scoped human approval, a verified pull request, deployment, the live result, and the audit evidence left behind.
Read the visual transcript
00:00 - The live Fine's Gallery storefront shows product dimensions fixed in US units. 00:09 - The operator asks the agent in Slack to design and implement an imperial/metric preference without breaking existing product pages. 00:17 - The agent inspects the application and returns a proposed solution with visual mockups for review. 00:23 - The agent prepares the implementation and presents the exact external action for human approval. Nothing ships until the operator approves that scoped plan. 00:33 - The approved change becomes a pull request with modified files and verification evidence, then merges and deploys through the existing delivery path. 00:45 - The production storefront displays the completed unit toggle across multiple product types. 00:55 - CloudWatch records the request, tool activity, approval, and response inside the client's AWS account, leaving an auditable trace of the run.
Where this engagement starts
The problem
Fine's Gallery runs a custom AWS commerce platform with a Next.js storefront, Payload CMS, event-driven order processing, payments, and background services. I remained responsible for operating and extending that platform after cutover. The agent work began inside that ongoing operating relationship, using AI to improve investigation, maintenance, content operations, and sales support without transferring control of the system.
The goal was to put an AI agent into that operational loop without choosing between two bad extremes: a sandboxed assistant that could only talk about the work, or one broad production identity trusted to do everything. The system needed to investigate real conditions, prepare real changes, prove what it had done, and gain additional access one capability at a time.
The next bottleneck after modernization
Fine's Gallery already had the hard foundation: a custom Next.js storefront, Payload CMS, event-driven order processing, Postgres on RDS, ECS Fargate, Lambda, and Terraform inside its own AWS organization. That platform replaced the operational limits of the legacy system and gave the business one coherent source of truth.
The next constraint was attention. Diagnosing a production question meant moving between AWS consoles. A content change required knowing the CMS's actual block and rich-text rules. An engineering request required repository context, a safe migration path, and evidence that the change worked. Those are not chatbot questions. They are operational workflows that cross systems and carry consequences.
I built a single-tenant operations agent to take on that connective work. The objective was not maximum autonomy. It was useful capability with a clear path to earn more access.
One platform, three agents
The deployment has since grown into three agents with separate identities: an engineering agent, a content agent, and a sales support agent. They are built from one codebase and one container image, but each runs on its own dedicated runtime with its own IAM role, its own Slack identity and channel, its own approval store, and its own memory. A single capability manifest drives both the code that registers each agent's tools and the Terraform that attaches each capability's least-privilege policy, so what an agent can do and what it is permitted to do cannot drift apart.
The separation is structural, not organizational. The content agent has no path to repositories, infrastructure, or the production AWS account: those credentials are simply never issued to its runtime, and its role carries no permission to read them. The engineering agent, in turn, has no credential for the live CMS. Boundary tests in the suite assert the tool sets stay disjoint at every sensitive edge, and each agent is instructed to hand work outside its lane back to the operator with a pointer to the right channel rather than improvise around the boundary.
Architecture
Three isolated agents, one codebase, inside the client's AWS organization
Isolated agent lanes from one codebase in the client's AWS organization. Each lane runs on its own runtime with its own IAM role, Slack identity, approval store, and memory. A single capability manifest drives both the code that registers an agent's tools and the Terraform that attaches each capability's least-privilege policy. The deployment now runs three lanes: engineering, content, and sales support.
A non-technical operator runs production content
The strongest evidence for the governance model is who uses it. Production content for the storefront, a business doing millions in annual revenue, is now operated day to day by a non-technical member of the Fine's Gallery team, working in a plain Slack channel. No mention syntax, no commands, no model names to learn: a routing layer classifies each request and picks the appropriate depth automatically, and a single button escalates any answer that needs more thought.
Making that safe did not mean writing a manual. It meant changing the design. The one tool that could call arbitrary CMS endpoints was deleted outright and replaced with typed, purpose-built tools behind a fail-closed policy engine: the operator's agent can edit editorial fields, and it structurally cannot touch pricing, inventory, orders, customers, or payment records, because those collections and fields are absent from its policy. Brand voice, approved claims, and editorial review gates are encoded as machine-checkable rules the agent runs against its own drafts. Photos dropped into the channel are actually inspected by a vision model before the agent writes captions or alt text, so visual judgments come from pixels rather than filenames.
Every publish still stops at an approval. What changed is who can safely drive everything up to that point.
The captures that follow are unaltered production threads, not interface mockups.
Content lane evidence
A request, an approval, and a verified draft
The agent resolves the live Payload schema, proposes a five-block rewrite using existing media, names the exact gated CMS write, waits for approval, saves the result as a draft, and verifies that the published page remains unchanged.
Content lane evidence
The published page before the request
The published About page before the request: a short text section and one showroom image remain live while the proposed replacement is prepared separately.
Content lane evidence
The draft produced by the approved write
The draft preview after the approved write: the same public facts and existing media are reorganized into a richer editorial page without publishing over the live version.
The content lane: SEO intelligence and social publishing
The content agent has grown well past drafting copy. It now runs a closed-loop SEO practice against the live storefront: snapshot search performance from Search Console and GA4, score opportunities against the site's own click-through curves, classify each one before acting, prepare governed CMS changes, verify the rendered result on the live site, and then measure outcomes over fixed windows where an honest verdict, including inconclusive, is recorded against the original hypothesis. Keyword research, competitor gaps, rank tracking, and technical audits come from Semrush behind a hard, fail-closed research budget the agent cannot override. Every number it reports carries its source and snapshot date, and sampled or incomplete data is labeled as such before conclusions are drawn. Opportunities that turn out to be engineering problems are not improvised around: the agent produces a structured handoff for the engineering lane instead.
The same agent operates social publishing across Pinterest, Instagram, Facebook, and Google Business Profile through the open-source payload-plugin-socials, the publishing engine documented in its own article on this site. Posts are composed from real CMS records and media, previewed exactly as each platform will render them, validated against per-platform rules, and published only through the same human approval gate as everything else, with idempotency guarantees that make a duplicate public post structurally impossible. The video above is this exact capability running in production.
Content lane
An SEO analysis the operator can ask for in one sentence
The content agent answers in the channel with a grounded report: the run identifier and snapshot date, the exact Search Console and GA4 window, the live Semrush pull with its remaining research budget, then headline numbers and ranked critical issues. Data-integrity caveats are stated before the conclusions, not after.
Content lane
One request, three platforms, and an honest report back
The operator describes an arriving product in a sentence and asks for posts. The agent drafts the copy, waits for approval, publishes to Instagram, Facebook, and Pinterest, and returns the live links with their audit rows. It also volunteers what did not go perfectly: Facebook resolved the post to a link card rather than a carousel, and an earlier failed attempt is recorded in the audit trail. An agent that reports its own imperfect results is one you can leave running.
The engineering lane, unchanged where it matters
The engineering agent kept the original deployment's full operational surface: production health investigation across ECS, alarms, logs, and recent-change history through a read-only cross-account role that structurally cannot reach customer data; cost analysis from the client's own billing data; and engineering changes prepared in disposable repository clones, navigated structurally, verified, and proposed as draft pull requests with evidence attached. Its lane hardened in the same release that created the content agent: even its private preview bucket now sits behind the approval gate, and every Slack ingress decision, accepted or rejected, is written to the audit record.
Engineering lane evidence
Read-only production triage in one thread
The operator explicitly prohibits changes. The agent correlates desired and running task counts across four ECS services, active CloudWatch alarms, the most relevant recent errors, and CloudTrail activity from the preceding hour. It identifies the one operationally meaningful aged-queue alarm, distinguishes benign errors from service-health failures, and reports no recent deployments or IAM mutations.
The sales lane: the commercial back office, governed the same way
The third agent supports the sales side of the operation, and its design answers the question every owner should ask before letting software near revenue: what exactly can it touch?
Its foundation is a data lake: a read-only mirror of the company's decades-deep document archive, customer files, job folders, scans, and yearly inquiry records, synchronized from the on-premises NAS into object storage inside the client's own AWS organization. A nightly crawler maintains a queryable index of the archive, so the agent finds files across roughly two decades of records with an Athena query instead of a crawl, then fetches exactly the documents it needs. The mirror is read-only by construction, and the sensitive trees, accounting, HR, and bookkeeping, are excluded by explicit deny rules in the storage permissions themselves. The agent cannot list those folders, let alone read them.
On top of that archive it does the connective work that used to eat staff hours: briefing a salesperson before a customer call with the full history in hand, looking up customers and orders, drafting invoices with the platform's real numbering and rate rules, and preparing replies in the sales mailbox. The mailbox integration is deliberately lopsided: the agent can read and it can draft, and it structurally cannot send, because the account grant it runs under does not include a send permission. A human reads every draft and presses send themselves.
The write surface follows the same philosophy. Of the dozens of record types in the platform, the sales agent can write to exactly three: orders, draft invoices, and address books, each restricted to an explicit list of permitted fields. Customer identity records are read-only. Payment amounts and links are never composed by the agent at all: a payment request goes through the platform's own issuing endpoint, which mints the secure link and emails the customer directly. And every one of those writes, like everything else in the system, stops at a human approval in Slack before it happens.
Talking to the system: voice memos in Slack
The newest capability is the most human one. Staff can hold the Slack record button, describe what they need, and let go. The pipeline acknowledges the memo, transcribes it server-side with Amazon Transcribe inside the client's account, echoes back what it heard, and then proceeds exactly as if the request had been typed, approvals included.
The engineering around that convenience is deliberately unglamorous. Audio is fetched only from Slack's own hosts over a hardened downloader that refuses redirects. Clips are size-capped and staged in a private, encrypted bucket that exists only for the seconds the transcription job needs, then deleted. The transcript text is never written to logs. And the system never guesses: if a clip cannot be transcribed, the operator gets a plain-language failure in the thread, not a best-effort interpretation silently acted on. For a team that lives on the road and in the showroom, dictating a request instead of typing it is a real, daily time saving. For the architecture, it is just another input to the same governed pipeline.
The access model is designed to grow
The initial deployment deliberately starts with a narrow production posture. Operational observability can read service health without customer records. Content work is draft-first. Repository work stays local until a human approves the external step. That is the right place to begin because it creates value while the system builds an evidence trail.
It is not a permanent limit. The next useful capabilities include work with operational records and invoices. Those do not require giving the entire agent unrestricted database access. They require purpose-built tools that expose the minimum fields and actions for the task, a policy attached to that capability, and an approval or verification rule matched to the consequence of being wrong. This is how the agent becomes more useful without turning every new workflow into a system-wide security exception.
Auditability, shown
The decision log, in Fine's own CloudWatch
Every invocation across all three lanes lands as a structured event in a vended log group inside Fine's AWS organization: the operator's request in plain language, severity, session, and trace identifiers. The client's team can audit what the agents did last week without asking anyone's permission. Identifiers redacted here; the record itself is exactly as it appears in the client's account.
The model is replaceable. The operating layer is the asset.
The agent can use models available through Amazon Bedrock and route tasks by the capability, latency, and cost they require. No business integration is written around one model family's private API. Change the model selection and the approval records, IAM boundaries, Payload knowledge, repository tools, and observability continue to work.
That distinction protects the investment. Models will change faster than the business systems around them. The durable work is encoding how the business operates, what each capability may do, how success is verified, and who decides when the agent crosses a consequential boundary.
Start with the operation that keeps stealing senior attention
A $10K Agent Architecture Sprint is enough to map the workflow, systems, access boundary, failure modes, and cost model. A focused Agent Production Build starts at $25K. Thirty minutes is enough to decide whether your first workflow belongs in that process.
Outcomes
Outcomes (with sources)
Real metrics with attribution. Numbers without sources read as marketing. Every claim here is sourced.
Metric
Production triage
Before
A production-health question required a person to move across multiple AWS consoles and correlate the evidence manually.
After
A Slack request returns current ECS service state, task counts, alarms, log evidence, and recent-change context from the live AWS environment.
Source: Live Fine's Gallery deployment; CloudWatch, ECS, and CloudTrail tool evidence
Metric
Content operations
Before
A safe CMS change required an operator who understood the live collection, relationship, block, and Lexical document shapes.
After
The agent prepares Payload CMS documents using the site's real schema and rich-text rules, saves work draft-first, and separates publishing into its own approved action.
Source: Production Payload content capability and approval records
Metric
Engineering workflow
Before
A routine application change still required a senior engineer to gather repository context, make the edit, run checks, and package the review by hand.
After
Engineering work happens in a disposable clone, with structural code navigation and required checks; external delivery becomes a human-approved draft pull request carrying verification evidence.
Source: Repository skill, pull-request gate, and CI evidence
Metric
Governed expansion
Before
The apparent choice was a harmless assistant that could not finish work or broad production access that was difficult to defend.
After
Each new capability brings its own tools, permissions, audit events, and approval or verification rules. Access can extend into records and invoices without granting a universal agent role.
Source: Skill-scoped IAM and tool-boundary architecture
Metric
Delivery
Before
The capability existed only as a design question: could an agent do useful operational work without becoming an uncontrolled actor?
After
A production deployment in six weeks with client-controlled infrastructure, gated external actions, end-to-end audit evidence, and no long-lived AWS credentials in the delivery path.
Source: Repository history and production runtime deployment records
Metric
Content operations ownership
Before
Storefront content changes queued behind the consultant or technically-confident staff, and social posting was manual per platform.
After
A non-technical team member drives CMS drafts, SEO work, and four-platform social publishing from Slack, with every publish held for approval.
Source: Live Fine's Gallery deployment; content-lane audit records
Metric
SEO practice
Before
Search performance review was ad hoc, and optimization work was unmeasured after shipping.
After
A closed loop runs from Search Console, GA4, and Semrush snapshots through governed CMS changes to live verification and fixed-window measurement with recorded verdicts.
Source: Content-agent SEO state store; experiment lifecycle records
Engineering memo
Key decisions
What was decided, why, and what was deliberately not done.
Deploy the agentic infrastructure inside the client's own AWS organization.
Rationale
The runtime, request gateway, approval records, audit logs, secrets, and deployment pipeline remain under accounts the client controls. Amazon Bedrock AgentCore runs the agent over IAM-authenticated invocation rather than a public endpoint. A dedicated deployment keeps business context and operational credentials within the client's environment instead of combining them in a shared agent control plane.
Alternative considered
A shared SaaS agent control plane that places operational credentials outside the client's AWS boundary.
Keep model choice separate from business capability.
Rationale
The agent can evaluate and route across models available through Amazon Bedrock without rewriting its skills, integrations, permissions, or audit path. Routine classification, operational analysis, and deep engineering work can use different capability and cost profiles. As the model catalog changes, the operating layer remains intact.
Alternative considered
Hard-wire the operating system to one model family and pay the same latency and cost for every task.
Grant access capability by capability, with a defined expansion path.
Rationale
The first production phase began with operational metadata, cost data, draft-first CMS work, and gated engineering actions. Each skill carries its own instructions, tools, and IAM policy fragment. Future capabilities, including scoped work with invoices, records, or customer operations, can receive only the fields and actions they need, with separate logging, verification, and approval rules. Access is staged, not frozen.
Alternative considered
Choose between an assistant limited to recommendations and one broad agent role that can reach everything.
Enforce approval and verification where tools execute.
Rationale
A git push, pull request, CMS publish, or AWS change generates a concrete plan and waits for a human decision in Slack. The approval expires after one hour and applies only to that plan. Tools that affect live behavior return a requirement to verify the result, and every tool call records its inputs, outputs, request, session, and approver. Governance does not depend on the model remembering a rule.
Alternative considered
Rely on prompt instructions to make the model ask permission and trust its own report that a change succeeded.
Split the platform into per-domain agents instead of widening one.
Rationale
One codebase and one image deploy as three agents with separate runtimes, credentials, Slack identities, and approval stores. A shared capability manifest drives both tool registration and IAM attachment, so capability and permission stay provably aligned. The content agent carries no path to repositories or infrastructure; the engineering agent carries no credential for the live CMS. That isolation is what made it safe to hand the content lane to a non-technical operator while the engineering lane kept its senior-only surface.
Alternative considered
One agent with the union of every permission, separated only by prompt-level personas that a confused model or a clever request could cross.
What the client said
“Mr. Peter, as our technology partner, built our entire commerce and operations platform from the ground up on AWS. It runs our website, our orders, our invoicing, our payments, everything. Migrating to the new system was seamless, with no interruption or data loss. Peter is honest, a strong communicator, and when something needs attention, he takes care of it fast. I trust him with the most important systems in my company. Highly recommended.”
Read more
Technical analysis behind Fine's Gallery: AI Operations Agents for Real Work
The Sovereign AI Agent: Production Ops in an Account You Own
A production pattern for client-owned AI agents on AWS, now running at Fine's Gallery with scoped tools, human approval, audit evidence, and no hosted-agent lock-in.
Building a Production Social Media Plugin for Payload CMS
A production Payload CMS social media plugin for Pinterest, Instagram, Facebook, and Google Business Profile, with scheduling, AI-safe tools, and 1,146 tests.
More case studies