Helm: A Marketing and E-Commerce Team in Software

What it does

Helm is a marketing and e-commerce department expressed as software. You add a brand, connect its accounts, set a budget and a level of freedom, and a defined team of AI roles plans, writes, publishes, prices and measures.

In short. Helm is a team with an org chart, a rulebook and a ledger. It is not a chatbot with a marketing prompt.

The problem I wanted to test

A small brand cannot afford a marketing department, yet the work is broad: strategy, copy, listings, advertising, pricing, reporting. The owner does all of it in a hurry, with no second opinion.

I set two conditions before writing any code:

• Every action, decision and cost goes on record. Nothing happens off the books.
• Spending is limited by code, not by a polite request. A prompt can be argued with. A limit enforced by the program cannot.

I built it for a small handcrafted-goods brand that I operate myself, with a live Amazon.in storefront. I kept the design brand-agnostic, and I started a second brand on it.

What is in it

The numbers, as of my own review on 1 September 2026:

• 73 agent roles in 16 departments
• 131 action types, each a defined piece of work with its own form, procedure, approval gate and outputs
• 27 recorded runs, 39.8M input tokens, $41.70 total recorded cost
• 3 recorded debates between roles

It runs on Claude

I want to be unambiguous here. Helm runs on Claude, through Claude Code in headless mode, with Claude in Chrome for anything that needs a browser. It is not a small-model or open-model system. The roles are split across tiers: 10 on Opus for judgement (Brand Strategist, Copy Chief, Judge, Head of Growth, Planner), 44 on Sonnet for evidence and rule work, 17 on Haiku for sorting and polling, and 2 that inherit the caller’s model.

How it is built

The design keeps three things apart: the model that reasons, the code that decides what it may do, and the connectors that touch the outside world.

Four layers

• The portal. A React app on localhost, with one menu entry per department. It is where the owner sees work, approves it and sets limits.
• The engine. A Python FastAPI backend holding the job queue, a dependency graph, the scheduler, the policy checks and the kill switch. State lives in SQLite, 59 tables in all.
• The runtime adapter. A narrow interface that starts a Claude Code session (claude -p, streaming JSON events) for one job and reads back an outputs.json manifest. An Agent SDK adapter is stubbed behind the same interface.
• The connectors. For each platform, up to three modes: API, browser through Claude in Chrome, or manual import. Credentials sit in an AES-256-GCM encrypted vault that no run can read.

Actions, roles and skills

An action is defined once as a small file: its inputs (which become a form), the roles that work on it, its approval gate and its estimated cost. Beside it sits a SKILL.md, the procedure the model follows. A job is one instance of an action; a run is one execution of a job, with its model, token counts and cost recorded.

Each run is frozen at launch into its own folder with the exact prompt and inputs, so every result is auditable.

The org chart

The 73 roles sit in 16 departments. The main ones:

Department	What it owns
Leadership	Goals, the daily cycle, compliance checks, budget and approvals
Brand and Strategy	Positioning, voice, brand kit, competitor teardowns
Products and Economics	Catalogue, unit economics, fees, margins, inventory, offers
Creative Studio	Images, video, shot lists, prompt packs, a quality gate
Marketplaces and Catalog	Listings, A+ content, listing audits, price monitoring
Analytics	Data pulls, attribution, forecasts, weekly reports
Knowledge	Seven scouts for trends, festivals, competitors and platforms
Council	The debate cast: Proposer, Critic, Skeptic, Judge

Every action card says whether it runs straight through, needs approval first, or lands for a look afterwards, and carries a plain cost label.

Economics is the department that earned its place

Unit economics is where Helm is most precise. It computes contribution per product per channel from real fee schedules: commission, closing fees, shipping by zone, returns, ad cost per order. It marks every assumed number and lists what is missing.

That screen shows the dependency plainly. Without a cost price, nothing can be priced, discounted or reported on honestly, and the cost price is the one number Helm cannot discover by itself.

Marketplaces through the browser

Where there is no API, Helm hands a narrow task to a Claude in Chrome run: update a price, read an ads console, audit a listing against the marketplace’s own rules.

A run, step by step

Here is one pass through the system, the way it was designed to work. The stages are numbered so you can follow them without reading the prose.

  Owner sets the rules
        |
        v
  Planner proposes jobs
        |
        v
  Code checks the rules --> blocked
        |
        v
  Gate: run / ask / refuse
        |
        v
  Headless Claude run
        |
        v
  Owner's approval tray
        |
        v
  Connector ships it

Before anything runs

1. The owner sets five decisions once. What the team may work on, how far ahead it plans, what it may spend, how much it may do without asking, and when it must stay quiet.
2. The Planner proposes the day’s jobs. It reads the goals, the festival calendar, inventory, the economics and the scouts’ findings, then writes a digest and a list of proposed jobs.

3. A job is created for each proposal. It carries its action, inputs, gate and dependencies.

The check that does not trust the model

4. Python checks the job against the rules. Budget envelope, margin floor for that product and channel, channel allow-list, quiet hours, kill switch. The verdict is one of three: allowed, needs approval, or blocked with the reason shown.
5. The gate decides who acts next. Each action carries one of four gates: none, review, approve or two-step.

The work and the hand-off

6. A headless Claude run does the work. It follows the action’s SKILL.md, calls the roles it names, and writes files only inside its own job folder. It ends by writing outputs.json.
7. A debate runs if the decision is large. Strategy, offers and campaign plans can go to the council: proposers work blind and in parallel, then a critic, a skeptic and a judge. The verdict, weighted score and ideas grafted from losing proposals are recorded.
8. The owner works the approval tray. Approve, revise (which resumes the run) or reject.
9. A connector ships it. Only then does anything leave the building, and every step writes to the audit log, the budget ledger and the brand log.

The loop afterwards

10. Results flow back. Platforms report sales, ad results and reviews. Analytics writes a weekly review the owner can read in five minutes. Approved learnings become knowledge that the Planner and scouts use next time.

Which of those steps ever ran

I have to be precise, because the diagram above describes the design. The headless run in step 6 worked. Claude sessions started, produced files and recorded their costs. Step 9 never ran, and the chain as a whole never ran end to end. The approval tray recorded only 5 approvals, 1 of them decided. The write paths degraded to a note, and nothing was ever shipped through a connector. The section on what failed returns to this.

The controls

I built the controls before the clever parts, because they are the point of the exercise.

The control. Limits run in Python before and after a model call. They never depend on the model following an instruction.

What code enforces

Guardrail	What it blocks
Budget envelope	Ad launches, creator payouts, paid tools
Margin floor, per product and channel	Offers, coupons, deal enrolment, bid increases
Channel allow-list	Posting or emailing on any channel not enabled
Quiet hours and blackout dates	Any outbound action at the wrong time (default 9pm to 8am)
Approval policy by action type	Decides the gate at each autonomy level
Kill switch	Halts the queue, cancels runs and blocks outbound until reset

Four rules every run obeys

• A run writes only inside its own job folder. Brand-level changes arrive as proposals.
• A run never touches a secret. Keys stay in the encrypted vault.
• A run never ships. Gates and connectors do.
• A run never invents a number. A gap becomes a visible [TO VERIFY] marker and a question.

What the owner decides

The auto-run screen asks five questions, then previews what they mean for the next 30 days: how many posts, offers and listing fixes, how many approvals a week, and roughly what the team costs to run.

The autonomy setting has three levels:

• Ask me first. Nothing leaves without a yes.
• Ask before anything public or paid. The default. Drafts and analysis run free; posts, price changes and spending wait.
• Just tell me what you did. Everything still runs inside the guardrails, with a daily digest.

For the first seven days everything outward waits for approval whatever level is chosen.

Why it matters. In real use the guardrails were the most valuable thing in the system, and none of them needed a screen.

What it cost and what it produced

The recorded cost

Across 27 recorded runs, Helm used 39.8M input tokens and about 297,000 output tokens, for a recorded total of $41.70. That is the cost Claude Code reported for each run. The design was to work under my Claude Code subscription, so treat it as a measure of consumption rather than an invoice.

The judgement-heavy jobs cost most: a brand-kit run with a full debate about $16, a festival-calendar run about $4. A second brand added 8 orphaned runs costing $9.31.

What it cost. $41.70 for 27 runs over roughly ten days. The cost of building and maintaining about 68,000 lines of code was far larger and is not in that figure.

What it produced

• 74 artifacts, mostly Markdown documents: a brand kit, a voice guide, research, audits.
• A festival calendar of 164 proposed items, all of which are still marked as proposed.
• 3 debates with scored verdicts, one of which caught arithmetic errors in the critic’s own contrast table.

What it did not produce

The number. No sales or profit result is recorded for Helm. The outcome dataset is 2 ad-performance rows.

I will not claim that Helm made the brand more money, because the record cannot support that. Orders, inventory, reports and customer data tables were empty. The ad ledger showed Rs 0 against about Rs 2,257 of real spend. The window was ten days, for one brand and one operator.

What worked and what did not

What worked

• The guardrails, as encoded reasoning. The margin floor stopped a discount stack that would have lost money on every unit. A read-back rule caught five of six price changes that the marketplace had confirmed and then silently dropped. An “absent beats estimated” rule stopped a missing cost reading as zero.
• The economics engine. A fee-band fix found apparel brands being charged 17% where the marketplace charges nothing, and corrected an apparel band that was being applied at 17% instead of 18%.
• The debate as a record. An 18-agent debate reviewed a live advertising campaign. It cut it to eight exact keywords and a budget of Rs 100 a day from Rs 300, with every reason on file.
• The 131 skills. They worked without friction, because they meet the work where the work happens.

Where it failed

Where it failed. Helm’s execution layer never ran end to end. My own review called the web app “a notebook, not a cockpit”.

I wrote that review on 1 September 2026, after a week of running the brand’s Amazon account through Helm. These are the findings, stated as I wrote them.

• I bypassed the app every time. I built the campaigns, changed prices, paused keywords and cut the budget in the Amazon console, then recorded them in Helm afterwards.
• The job queue, the gates and the approval flow never executed. Every write path logged that no runtime action existed and degraded to a note.
• No brand-building job ever reached “done”. The two most consequential, a brand kit and a festival calendar, sat waiting for me from 24 August.
• I never opened the front end. There are 85 React components. I used 131 skills and none of the components.
• The debate ran outside Helm. The tables could store one, but Helm could not run it, so it ran in a Claude Code session and was recorded afterwards.
• The app was starved. Zero orders, inventory or reports, and a cost recorded for two of eight products.

The diagnosis

The domain logic is only about 4,350 lines of roughly 60,000. The rest is plumbing and interface serving that core.

The mismatch is structural. A web app is right when someone needs state at a glance, several people share it, or something must run unattended. Helm has one user, already in a terminal with a model that can drive a browser. Each screen translates work the model was going to do anyway, and a layer that has to be opened loses to one that is already there.

Two smaller lessons

• The debate was retrospective. I asked “did you do agent debate before deciding on the campaigns?” after the changes were made, so the debate adjudicated decisions already executed.
• It never used its own voice guide. The system wrote a rigorous voice document and never produced one piece of customer-facing copy with it.

What I would build differently

My review recommended option B: retire the web front end and keep the domain library, the 131 skills, the 34 browser playbooks and the tests, with Claude Code as the cockpit. I agree with it.

The plan, in order

1. Prove the library works standalone. Done on 3 September 2026: the fee engine runs in a bare Python process and FastAPI never enters the import graph.
2. Fix the join between systems. Helm held design-level product codes; the marketplace holds variants. Nothing can attach until they meet.
3. Write one skill per real capability. Check a price, read the ads console, propose an ad change, review campaigns, land a report.
4. Archive the frontend on its own branch.
5. Feed it orders, inventory, spend and the missing costs, so it is asked a question against real sales data for the first time.

What I would keep

• Guardrails in code. They were never in the UI and they survive the move.
• Frozen, auditable runs. Every result traceable to its exact prompt.

One loss deserves naming. A web app can show a brand owner their state without a terminal. If the owner were ever to open Helm himself, option B forecloses that, which is why I archive the front end rather than delete it.