Three Layers of AI: How One Person Built an Enterprise Amazon Operating System

Most companies use AI to write code. We use AI to write the code, run the operations, and be the interface. Three layers, one system, one person.

CorditeOS is an operating system for Amazon sellers. It ingests data from every corner of a seller's business — orders, inventory, ads, listings, competitors, search trends — transforms it into actionable intelligence, and then acts on it. Pricing adjustments, inventory replenishment, listing fixes, ad optimization, competitor tracking. The full lifecycle.

I built the entire system alone. Not a prototype. A production multi-tenant SaaS with a lakehouse data pipeline, six autonomous AI agents, a conversational AI assistant, and a dashboard covering every operational surface of an Amazon business.

This is how.

---

The Thesis

There are three ways AI shows up in CorditeOS.

Layer 1: AI builds the system. Claude Code is my engineering team. It writes the code, runs the tests, enforces conventions, and ships features. The codebase is designed to be legible to AI — a monorepo with structured documentation that teaches the agent how everything works.

Layer 2: AI agents run seller operations. Six specialized agents continuously analyze seller data, detect issues, and execute fixes. A pricing agent catches margin erosion and adjusts prices. An inventory agent spots stockout risk and triggers replenishment. An ads agent identifies wasted spend and reallocates budgets. They don't suggest — they act, within guardrails.

Layer 3: AI is the interface. The primary way sellers interact with their business is through a conversational assistant that knows their data. It queries live P&L, inventory health, ad performance. It compares ASINs, generates strategy briefs, creates action items. The AI isn't bolted onto a dashboard. The AI is how you use the product.

Most products have one of these layers. Some have two. CorditeOS has all three, and they compound. The agents find issues in the data pipeline's output. The assistant surfaces what the agents found. The development layer iterates on both at the speed of a single person making decisions.

---

Layer 1: AI Builds the System

I don't use AI as a coding assistant. I use it as my engineering team.

The entire codebase is a Turborepo monorepo: the Next.js dashboard, the Python data pipeline, the AI agents, the operations engine, the AWS CDK infrastructure. Everything in one place. This wasn't a convenience decision. It was a harness engineering decision. The more of your system the AI can see, the better it reasons about cross-cutting changes.

The key artifact is a structured documentation file at the root of the repository that teaches the AI agent the entire system: the architecture, the conventions, the gotchas, the API patterns, the database schema, the deployment pipeline. When I say "add a new report type to the pipeline," the agent knows what that means — which files to create, which configs to update, which SQL models to write, which sync targets to register. It doesn't guess. It follows the system's own operating procedures.

On top of that, I've built custom skills and hooks that enforce conventions automatically. A pre-write hook blocks commits that violate naming conventions, put files in the wrong directories, or accidentally include sensitive data. Custom command workflows handle operational tasks — checking pipeline health, debugging ingestion failures, managing infrastructure. The AI doesn't just write code. It operates within a system of constraints that makes its output reliable.

The CI pipeline runs on every change: linting, typechecking, unit tests, builds. Separate workflows handle daily data ingestion, weekly competitor discovery, and service deployments to ECR. When code changes in a specific package, only that package's container gets rebuilt and deployed.

The result: I ship production features daily. Not prototypes. Not demos. Production code running against real Amazon seller data, with real SP API integrations, real Spark clusters, real Supabase databases.

A common reaction is that this must mean lower quality. The opposite is true. When one person makes every decision, there's no alignment overhead. No design-by-committee. No six-week sprint cycles. No "let me sync with the other team." I see a problem, I fix it, I ship it. The feedback loop is minutes, not months.

---

Layer 2: AI Agents Run Seller Operations

This is where CorditeOS stops being a dashboard and starts being an operating system.

Six specialized agents run continuously, each focused on a domain of the seller's business:

The Pricing Agent detects negative contribution margins, lost Buy Box, and competitive undercutting. It calculates the optimal price adjustment and its revenue impact, then either recommends it or executes it automatically depending on the seller's comfort level.

The Inventory Agent monitors days of cover, velocity trends, and storage costs. When a product is heading toward stockout, it triggers a replenishment plan. When inventory is aging into long-term storage fees, it flags it for liquidation or promotion.

The Listing Agent catches suppressed or inactive listings — problems that silently kill sales. It identifies the root cause and submits fixes through the SP API.

The Ads Agent analyzes advertising efficiency across campaigns. High ACOS, wasted spend on irrelevant keywords, budget-capped campaigns leaving money on the table. It adjusts bids, negates keywords, and reallocates budgets.

The Promotions Agent cross-references slow-moving inventory with product performance to recommend coupons and deals that actually make economic sense — not just discounting for the sake of velocity.

The Data Agent monitors the pipeline itself. Schema drift, ingestion failures, stale data. It routes infrastructure issues to an internal incident system before they affect seller-facing data.

The Action Pipeline

Every agent follows the same lifecycle: detect an issue, validate it against a schema, deduplicate it against recently seen issues, and write it to a central action queue. From there, the action moves through approval, execution, and monitoring.

This is where the guardrails matter.

Three layers of safety sit between an agent's recommendation and execution:

The first layer is hardcoded into each agent. A pricing agent can't propose a change larger than 15% in either direction. An ads agent can't set a bid below a floor. These limits exist because some mistakes are never acceptable regardless of context.

The second layer is tenant-configurable. Each seller sets their own boundaries — maximum daily price changes, budget ceilings, product exclusions. Different businesses have different risk tolerances.

The third layer is a system-wide allowlist of action types. If an agent proposes something the system has never seen before, it gets blocked.

Beyond the guardrails, there's a circuit breaker. If an agent produces too many failures in a short window, it pauses itself. And a rollback monitor watches KPIs after execution — if a price change tanks velocity or a bid adjustment kills impressions, the system auto-reverts.

Sellers don't start on full autopilot. The system ramps: recommend-only for the first weeks, semi-automatic after confidence is established, full automation only when the seller opts in. Trust is earned, not assumed.

Planning, Not Just Reacting

The agents don't only react to problems. A separate planning layer handles forward-looking operations:

Demand forecasting generates daily ASIN-level predictions using sales velocity, search volume trends, seasonality, and competitive signals. This isn't a simple moving average. It weights recent data more heavily than historical, accounts for marketplace-specific patterns, and handles cold-start scenarios for new products.

Replenishment planning uses those forecasts in a burn simulation — projecting day-by-day inventory levels to detect exactly when a product will stock out and how much to ship. It creates FBA inbound shipment plans through the SP API.

Procurement planning extends the projection through the full supply chain: FBA inventory, warehouse stock, open transfers, open purchase orders. It generates PO recommendations that respect supplier minimums and lead times.

Storage optimization analyzes inventory aging and identifies products that are burning money sitting in Amazon's warehouses. It feeds back into the other modules — blocking replenishment for overstocked products, reducing PO quantities for slow movers.

These modules talk to each other. A demand spike triggers replenishment. A storage warning blocks a pending PO. The system thinks across the supply chain, not in isolated silos.

---

Layer 3: AI Is the Interface

The dashboard has pages for everything — P&L, unit economics, inventory, ads, listings, competitors, category optimization. But the primary interface isn't a page. It's a conversation.

The Cordite Assistant is a Claude-powered chat that knows the seller's business. It has access to dozens of specialized tools that query live data: P&L summaries and trends, product performance across any time window, inventory risk assessment, ad efficiency analysis, returns breakdowns, catalog search, data freshness checks, period-over-period comparisons.

When a seller asks "how are my top products doing this month?", the assistant doesn't return a generic answer. It pulls their actual P&L data, calculates contribution margins, identifies trends, and highlights the products that need attention. It can compare ASINs side by side, generate strategy briefs with SWOT analysis, and create action items that feed directly into the agent pipeline.

This isn't a chatbot bolted onto a dashboard. The tools are the same data layer the dashboard uses. The assistant is an alternative interface to the same system — one that's faster for exploratory questions and strategic thinking than clicking through pages.

The insight here is that most seller tools present data and expect the human to figure out what to do. CorditeOS presents data, tells you what it means, and offers to do something about it. The three layers connect: the data pipeline produces the intelligence, the agents act on it, and the assistant makes it conversational.

---

The Data Foundation

None of this works without the data layer underneath.

CorditeOS ingests data from Amazon's Selling Partner API across multiple report types — orders, inventory, FBA fees, storage, listings, ads across Sponsored Products, Brands, and Display. It pulls search query performance data for demand signals. It enriches products weekly through Amazon's Catalog API for images, descriptions, and competitive pricing. It runs a multi-source competitor discovery pipeline using Keepa data, AI-powered search, and advertising targeting analysis.

All of this lands in an Apache Iceberg lakehouse running on Spark Connect. The architecture follows a layered transformation model:

Raw data preserves source schemas exactly as received. Staging models clean, type, and normalize — parsing XML, categorizing fees, converting currencies. Dimension models build channel-agnostic views: a product master that unifies listings across marketplaces, content scores, competitor relationships. Mart models produce the analytical output: a full P&L waterfall from revenue to CM4 per ASIN, inventory health with velocity and days-of-cover, consolidated ad performance, settlement reconciliation.

The SQL models are dependency-aware. A materializer topologically sorts them and executes in the right order — staging before dimensions, dimensions before marts. Models can run incrementally (MERGE for append-heavy data like orders) or as full refreshes (dimensions that need complete rebuilds for correctness).

Multi-tenancy is enforced at every layer. Every table carries a tenant identifier. The database layer uses row-level security so queries without proper authorization return empty results, not errors. Tenant credentials are encrypted at rest. The pipeline tracks per-tenant, per-report progress through a state machine, with exponential backoff for API rate limits.

The data layer isn't a feature. It's the foundation that makes the agents smart, the assistant useful, and the dashboard accurate.

---

What One Person Can Build

People hear "one person" and assume it's a limitation. It's a feature.

When I built CorditeOS, I didn't set out to prove that solo development works. I set out to build the best Amazon seller operating system I could. AI made it possible for one person to build what would traditionally require a team of dozens.

But the advantages go beyond speed. When one person designs the entire system, there's no translation loss between the data model and the API layer, between the API layer and the UI, between the UI and the user experience. Every decision is coherent because one mind holds the full context.

There are no alignment meetings. No sprint planning. No stakeholder reviews. No design-by-committee. When I see an opportunity, I build it. When I see a bug, I fix it. The feedback loop between observation and action is as tight as it can possibly be.

This is what the CREAO article calls the architect role — but without the organizational overhead. I design the standard operating procedures. I build the testing infrastructure. I define what "good" looks like for the agents. I critique every AI output. The difference is that I also ship it, because there's nobody else in the loop to slow things down.

The risk people worry about is quality. In practice, the constraints I've built — the CI pipeline, the hygiene hooks, the structured documentation, the guardrails — produce more consistent output than a team of varying skill levels and attention spans. The system enforces quality. I enforce judgment.

The honest part: it's exhausting. There's no one to delegate to. Every decision, every production issue, every infrastructure hiccup is mine. But exhaustion is temporary. Organizational debt is permanent. I'd rather be tired and fast than comfortable and slow.

---

What's Next

CorditeOS is built. The pipeline runs. The agents detect. The dashboard renders. The assistant answers.

What's missing is the closed loop.

The next phase is getting CorditeOS in front of real sellers — even a small beta group — and building the self-healing feedback loop that turns production signals into automatic improvements. A daily automated health check that queries pipeline metrics, clusters errors, scores severity, and surfaces issues before anyone notices. Automated triage that creates investigation tickets with full context. Post-fix verification that confirms the issue is actually resolved.

The agents will expand. Reimbursement auditing — detecting gaps between Amazon's adjustments and actual reimbursements, tracking the claim window, monitoring manufacturing cost submissions. Review automation — requesting product reviews through the SP API at the optimal timing window. These modules are designed and partially implemented. They're waiting for production traffic to validate against.

The architecture scales without linear headcount. Adding a new agent means defining its detection logic, its action schema, and its guardrail configuration. The action pipeline, the execution engine, the monitoring — all of that is shared infrastructure. The seventh agent costs a fraction of what the first one cost to build.

The same applies to new tenants. Multi-tenancy is built into every layer. Onboarding a new seller means adding their credentials and running the pipeline. The data models, the agents, the dashboard — all tenant-aware from the ground up.

One person built this. But one person doesn't have to run it forever. When the time comes to grow the team, the harness is already built. The documentation teaches the AI how the system works. The same documentation teaches a new engineer. The conventions are enforced by automation, not by tribal knowledge. The architecture is legible — to AI and to humans.

The question I get most often is "how is this possible?"

The answer is that AI doesn't just write the code. It runs the business.