Fine's Gallery: An AI Operations Agent for Real Work
Built in six weeks and operated from Slack, it investigates live AWS systems, prepares CMS and engineering changes, and stops high-impact actions at a human decision.
In six weeks, I deployed a single-tenant AI operations agent inside Fine's Gallery's AWS organization. Operated from Slack, its business-specific capabilities investigate production systems, analyze cost, prepare CMS and engineering changes, and route high-impact actions through human approval—while keeping the model layer replaceable and access expandable per capability.
Key Results
Deployment boundary
Dedicated client environment
Operational capability
Operations, content, and engineering
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. The platform removed the legacy system's limits, but operating it still required senior attention across consoles, repositories, content models, and deployment workflows.
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.
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.
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
Documentary evidence
Two production workflows, shown with their evidence
These are unaltered production captures, not interface mockups. The first thread shows read-only investigation across live ECS, CloudWatch, application logs, and CloudTrail. The second records a schema-aware CMS proposal, scoped approval, draft-only execution, and verification; the paired site captures show the published page before the request and the resulting draft preview.
Live AWS production triage
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.
Request, approval, and 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.
Published page before the agent's work
The published About page before the request: a short text section and one showroom image remain live while the proposed replacement is prepared separately.
Draft result after 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 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.
Architecture
One agent in the client's AWS organization
The model is one replaceable layer inside a larger operating system. Verified Slack requests reach an AgentCore runtime; business-specific skills connect to real systems; access expands per capability; high-impact actions wait for a human; every tool call produces audit evidence.
One Slack thread, real operational work
Slack is the operator interface because it is already where questions, approvals, and context move. A request is signature-verified, checked against an operator allowlist, deduplicated, and handed to the runtime asynchronously. The thread remains a working session, so follow-up questions carry context instead of starting over.
- Production questions: inspect ECS service state, alarms, logs, metrics, and recent CloudTrail changes instead of asking a person to correlate three consoles.
- Cost questions: query Cost Explorer for service-level spend, trends, and forecasts using the client's own AWS billing data.
- Content operations: prepare draft-first Payload CMS changes using the site's real collection, block, relationship, and Lexical rich-text rules; publish only through a separate approved action.
- Engineering changes: work in a disposable repository clone, navigate callers and blast radius structurally, run the required checks, and propose a draft pull request with verification evidence.
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.
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.
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.”
More case studies