The Layers Behind One Website Revision: How My AI Agent Stack Actually Runs

This morning, I opened the latest incremental revision of thekidneyexperts.com—the company website we had revised—and was blown away. This case study is published separately on my personal site, shreemulay.com.

Not because it introduced a giant new feature. It didn’t. The change was mostly taste: quieter article pages, better visual hierarchy, cleaner publication details, and fewer interface elements competing for attention. Small decisions made the whole site feel more intentional.

That reaction made me look behind the result. The interesting story wasn’t one magical prompt or one model producing a beautiful screenshot. It was the stack of layers that moved a subjective reaction—this page can feel better—into a bounded plan, reviewed code, tests, and a verified deployment.

This is a companion to my July note, How I Run AI Agents. That article described the broad idea. This one follows a single incremental revision and records the reusable setup as it runs today. It began when a colleague from my alumni WhatsApp group asked whether I used Claude Code or Claude Design for the site.

TL;DR

I start in OpenCode Plan, where permissions are restricted so the direction can be challenged before implementation begins. Plan isn’t universally read-only in every installation; its actual permissions depend on configuration. In mine, it is the place to inspect, reason, and establish the contract before a writer touches the repository.

Then OpenCode and the community-built Oh-My-OpenCode-Slim, or OMO-Slim, coordinate bounded specialist lanes. The planner, orchestrator, designer, explorer, fixer, librarian, observer, and read-only oracle do different jobs. They don’t share one vague instruction and race toward production.

Memory retrieves prior decisions. Tests define what must remain true. Forgejo protects review and merge. Cloud Build builds the image. Cloud Run serves it. I still decide whether the result has taste, whether the claims are accurate, and whether the work should ship.

Layer 1: Plan Before the Revision Becomes Code

The revision began with a fresh evaluation of the live site. The question wasn’t “Can an agent redesign this?” It was narrower: which small choices were making the reading experience feel busier or less deliberate than it needed to be?

That distinction matters. “Make it better” is permission to wander. A useful plan identifies the behavior to preserve, the exact surfaces that may change, the files a later lane can own, and the evidence that will settle whether the revision worked.

OpenCode’s agent documentation describes primary and subagent roles and configurable permissions. My planning route is google-vertex-anthropic/claude-fable-5-1, a local route backed by Fable 5.1. Anthropic describes Fable 5.1 as a model for demanding reasoning and agentic work. Here, it evaluates the whole page and proposes the smallest coherent revision.

OpenCode Plan is restricted in my setup, not universally read-only by definition. That precision is important. A role name isn’t a security boundary. Permissions and tools are. Before implementation, I approve the direction and turn it into an OpenSpec (living contract) with explicit non-goals and testable exit criteria.

Layer 2: The Harness and Orchestrator Hold the Boundary

OpenCode is the agent application. Oh-My-OpenCode-Slim is the community-built harness I use on top of it. OMO-Slim supplies the orchestration pattern without pretending to be the repository, the issue tracker, or the delivery system.

The orchestrator receives an approved contract and decomposes it. It decides which work can happen in parallel, which specialist owns each path, what must happen sequentially, and what evidence has to return. Its configured local OpenCode route identifier is openai/gpt-5.6-sol-fast; “Sol Fast” is not a vendor model name. OpenAI’s GPT-5.6 Sol documentation is the intended target and vendor reference for that route. Configuration alone does not prove which backend answered a particular runtime request; that identity would require evidence from the provider.

This is where the revision stopped being a loose aesthetic request. One lane could own visual judgment. Another could inspect existing article patterns. A writer could implement only approved files. Tests could be written before the article or assets existed. The orchestrator’s job was to preserve those boundaries while reconciling the results.

OMO-Slim’s background orchestration documentation explains why delegated lanes need lifecycle and result handling. Parallelism helps only when ownership is explicit. Otherwise it is just several agents creating incompatible state faster.

Layer 3: Specialist Lanes Do Different Kinds of Work

The specialist map is intentionally uneven.

The designer uses google-vertex-anthropic/claude-fable-5-1, the local route backed by Fable 5.1. That lane owns hierarchy, typography, responsive behavior, accessibility, and the felt quality of the page. For this revision, taste meant removing noise and making the article easier to inhabit—not decorating it with more components.

The fixer is configured with the local OpenCode route identifier openai/gpt-5.6-sol-fast for bounded implementation. The explorer and observer are configured with openai/gpt-5.6-luna-fast. OpenAI documents GPT-5.6 Luna separately from Sol; those vendor pages are the intended targets and references, while the local -fast names remain configuration labels. As with the orchestrator route, provider evidence—not configuration by itself—would be needed to establish the backend identity used at runtime.

The librarian checks current primary sources. The oracle uses claude-code/opus-readonly, a custom read-only route for hard architecture, debugging, and review. I do not claim that route is pinned to an Opus 5 backend. “Read-only” describes the custom route’s tool boundary, not a universal property of an Opus model.

Fallback is disabled as my configured policy. If an assigned route is unavailable, the lane stops rather than silently changing models. That makes failures less convenient, but it keeps the evidence honest: a result attributed to one route did not quietly come from another.

Layer 4: Memory Retrieves Context Without Becoming Truth

Agent sessions are temporary. Decisions shouldn’t be.

An MCP connection exposes bounded tools or services that agents can call. It is the connection and tool boundary, not the memory database itself. My memory implementation behind that boundary uses the Qdrant collection ai_memory_v3. Qdrant stores vectors with payloads and retrieves similar records. That lets a session recover relevant constraints and previous corrections without dragging every old transcript into the prompt.

ZeroEntropy’s zembed-1 creates embeddings. Its default output is 2,560 dimensions, with smaller outputs available when configured, as described in the zembed-1 API documentation. Then zerank-2 reranks retrieved candidates so the most useful records rise above merely similar ones. ZeroEntropy lists both in its model documentation and explains reranking in the zerank-2 API reference. Qdrant and ZeroEntropy are components of the memory implementation; neither one is MCP itself.

Memory can remind an agent that an earlier review rejected a pattern or that a deployment requires exact-head evidence. It cannot prove what is currently in the branch or what reached production. The repository, OpenSpec, tests, Forgejo, and live output remain authoritative.

That boundary protects the revision from confident nostalgia. A remembered decision is a retrieval lead. Current files and evidence decide whether it still applies.

Layer 5: Discipline Turns Taste Into a Durable Change

Taste starts the conversation. Discipline keeps it from becoming arbitrary.

For substantial work, the sequence is Bead (work ticket) → OpenSpec (living contract) → TDD → implement → local smoke → Forgejo PR → exact-head Actions (checks attached to the exact proposed commit) → protected merge → deploy → live verification → OpenSpec archive → Bead close.

The Bead tracks the work. OpenSpec defines why the change exists, what may change, what stays out of scope, and how completion will be tested. A RED test—a test intentionally failing before implementation—makes missing behavior visible before code is added. A writer receives exact path ownership, which prevents a focused article revision from turning into an opportunistic site rewrite.

This site uses Astro content collections for typed article metadata and static routes. That means the revision isn’t complete because Markdown looks plausible. Frontmatter, canonical discovery, social copy, images, accessibility, word count, and public-safety rules can all be checked as contracts.

The public account also has a deliberate boundary. Credential values, private identities, private project IDs, and subscription-rotation details are omitted. So are service accounts, private endpoints, private prompts, and patient information. The architecture can be useful without publishing the keys—or the private map—to it.

Layer 6: Delivery Proves Which Revision Actually Shipped

Code review happens in Forgejo, my Git forge. Forgejo Actions runs repository workflows, but the important property is exact-head verification: required checks must pass for the exact commit proposed for merge.

Branch protection remains in place. A protected merge to main triggers the Forgejo deployment workflow. Its deployment job uses keyless OIDC authentication, then the repository’s deployment script submits local source through gcloud builds submit. Cloud Build builds the container image. The script resolves the image digest and deploys that exact digest to Cloud Run as a no-traffic candidate revision.

The script validates the candidate and confirms that the existing revision still has all traffic before promotion. Only then does it promote the candidate to 100%, verify that exact traffic target, and run a live smoke check. A failed post-promotion step has a bounded rollback path to the previous revision.

I previously compressed that path into “GCS,” which was wrong. With gcloud builds submit, Google Cloud Storage (GCS) stages the local source for Cloud Build. The deployed container image is not hosted in GCS, and GCS does not host, run, or serve this website. Cloud Run is the runtime that serves the deployed company site.

That correction is more than cloud vocabulary. Each layer has a different responsibility. Forgejo proves which code was reviewed. Cloud Build produces the image. Cloud Run runs it. Live verification proves the public route, metadata, images, and links behave as intended after deployment.

Layer 7: Judgment Is the Layer I Can’t Delegate

The stack can inspect a site, propose changes, write code, run tests, and produce deployment evidence. It cannot decide what I mean.

In this revision, the strongest contribution was restraint. A quieter category label. A more readable line length. Publication metadata that looks like a colophon rather than another card. One primary action instead of several elements asking for attention at once.

An agent can identify those patterns. I still have to look at the result and decide whether the page feels clearer. I have to read the prose carrying my name, check the factual claims, and reject language that sounds polished but isn’t mine.

That is why I don’t describe the stack as autonomous. It is layered delegation under explicit constraints. The more capable the models become, the more valuable that separation gets. Strong output deserves strong review, not automatic trust.

A Practical Way to Start

Don’t start by copying every route and specialist in this article.

Start with one recurring change. Separate planning from implementation. Write down the exact paths a writer may touch. Add one test that fails before the work exists and passes only when the user-visible contract is met. Require a reviewed commit and verify the result where users actually see it.

Then add layers in response to real bottlenecks. Add an explorer when repository discovery overwhelms the main session. Add a designer when implementation agents are making aesthetic decisions they shouldn’t own. Add memory when confirmed decisions keep getting lost. Add an oracle when hard reviews deserve a separate, restricted lane.

Keep the names honest. A local route is not automatically the vendor model name. A “read-only” role is not safe unless its tools enforce that boundary. A green build is not a deployment. An artifact bucket is not the runtime. And an agent’s confident sentence is not your judgment.

This article started because a colleague from my alumni WhatsApp group asked whether I used Claude Code or Claude Design for the site. God willing, it will help someone implement a layered setup themselves instead of leaving the answer buried in a group thread.

Praise be to God, Lord of the universe. I’m grateful.

What are you building with agents that I should learn from?