Key Takeaways
- Training an AI agent is mostly a context-building job, not a prompting job. The context stack (design tokens, numbered build rules, component grammar, copy voice rules, checklists) is what makes the output good, not the model choice.
- Expect three to four months of iteration before an agent is genuinely useful. Naive chat-to-build and off-the-shelf agents both failed for us before the trained system started producing pro-level work.
- The point of training is inversion: a well-trained agent knows the brand rules better than the humans on the call, so the agent keeps the humans on the rails, not the other way around.
- Review gates are part of the training, not a step after it. Two to three gates per page, plus a translation-verification engine that diffs the CMS output against the approved HTML, are how you prove zero drift from strategy to shipped page.
- A single landing page used to take two to five weeks. Once the agents were trained, a page takes two to four hours, and one brand shipped 29 pages from 38 reusable components with no one writing code by hand.
I want to start with the thing I actually believe, because it took us three or four months of trying the wrong things to arrive at it. If you want good output from an AI agent, you spend almost all of your time training the agent. Not prompting it, not shopping for models, not wiring it into more tools. Training it. And by training I mean giving it so much context about your world, your brand, your rules, your voice, and your definition of good, that eventually the agent becomes smarter about that world than you are.
That inversion is the whole game: once the agent is deeper in the brand than the humans on the call, it stops being a tool you're keeping from hallucinating and becomes a partner that keeps you from hallucinating, correcting your instincts, catching your biases, and refusing to ship the sloppy thing you asked for at 4pm on a Friday.
We proved this to ourselves building landing pages and full websites, but the lesson is not about web builds. It's about how you train any agent to do senior work.
Here is what that actually looked like inside Mighty and True, in the order we lived it.
How to train an AI agent, in the order we actually did it
The first thing we tried was the thing everyone tries. We opened a chat window and asked it to build a page. It wasn't great, and we tried it enough times to be sure. Then we tried borrowed and off-the-shelf agents that other people had shared. Better, but still not close to something we would put a client's name on. That whole loop took three to four months of iterating before the output crossed the line into what one of our engineers, watching a demo, called "really pretty amazing." The iteration arc is the story. If you skip it you don't get the outcome.
What changed everything was building the context stack. This is the part of the meeting we spent the most time on, and it's the part most people underweight. The stack, for us, is a set of artifacts we authored and fenced the agent inside: design tokens, a strategy document, numbered brand and build rules, a component grammar, copy voice rules, and checklists for every review gate. One of our engineers put it this way in the demo: the magic isn't the AI model, it's the context the model reads before it writes a line. During the live build he narrated what the agent was doing out loud, and it was reading the brand contract, the tokens, the component grammar, and the build rules before it produced a single element. That is its world. Everything outside that world doesn't exist to it.
Once the stack existed, we put discovery agents in front of it. A web-inventory audit crawls the existing site so search equity carries over instead of getting torched on relaunch. A persona agent crawls keyword and SERP data and audits every legacy page against the personas we're actually trying to reach. One of our builders, who came from a drag-and-drop background and had never coded, told me that work would have been really, really hard to even figure out how to start manually. When a trained agent lets a non-specialist do specialist work at real quality, the training is doing its job.
The context stack is the product
From the master framework we generate a per-page document for every build. A build skill then assembles the page from approved components and locked tokens only. It cannot reach for an un-approved color, a rogue spacing value, or a component that hasn't been graduated into the design system. If it's unsure about something, it inserts a flag-as-TODO placeholder instead of guessing. That single rule, don't guess, flag, is most of what we mean when we say we've fenced hallucinations out.
The result, on one brand, was 29 pages live inside the CMS, built from 38 reusable components, with zero drift from the first strategy call to the shipped page — zero drift meaning the verification engine diffs the CMS output against the approved source HTML and finds no delta. Nobody wrote the code by hand. A single landing page used to take us two to five weeks. In the trained system it takes two to four hours.
I want to be careful here, because "two to four hours" sounds like a marketing line. It isn't. It's the time from a page doc existing to the page being ready for the first review gate, and it's fast because the build skill is assembling from tokens and components we already trained and approved, not inventing anything new. The training work that made those hours possible took months. You are trading months of system-building for hours of per-page building forever after.
Review gates are where the training compounds
We run two to three review gates on every page. Flow, design, copy, animations. Then a rigorous brand-review skill runs the page against the numbered rules. Then a translation engine converts the approved HTML into editable CMS modules, and a verification engine diffs the CMS version against the approved HTML to prove nothing drifted in the handoff. Page speed gets checked too. "Good" for us is a measurable thing: zero drift versus the source of truth, review-gate passes, page speed retained, and client reaction.
The most interesting moment in the demo was when the team broke a rule on purpose to see if the gates would hold. They built a component with a black icon circle, center-aligned, both of which our rules forbid on that brand. I said out loud during the build that I didn't think centering was a thing on that brand. The builder said, that's right, I want it centered anyway, let's try it. The agent complied, and while it was working it flagged inline that the centering and the icon color contradicted the numbered build rules, and that a CTA label was off the copy voice — before the formal brand-review skill had even run. We shipped the violation into review anyway. In one pass the brand-review skill caught the full set: the component was brand-new and would have to be graduated into the design document before it could be reused, the centered layout violated rule 16, the black icon circle violated rule 12, and the CTA label violated the copy voice rules. It also suggested removing an eyebrow text element that wasn't earning its space. They asked it to fix what it caught, refreshed, and the component came back left-aligned, in brand colors, on voice.
Nobody had to remember rule 12 or rule 16. That is the point. The agent remembers everything you'd forget, and it knows things you never knew.
The agents keep the humans on the rails
In an untrained setup, the human is the referee, spending their day catching the agent's mistakes. In a trained setup, the polarity flips. The agent is the referee, pushing back before you ask it to. A junior does what you say. A senior tells you when what you're asking for is wrong, does it if you insist, and logs it. That is what the agent had just done in the centering scene — complied, flagged, logged — and it's what senior work looks like.
Another moment that made this real for me: a client had built a comparison page on their own that basically looked like a generic AI page, off-brand in a way that was hard to name. We fed the page into the trained system and it rebuilt the whole thing in-brand in about 45 seconds, because the build skill was assembling from tokens and components it had already been trained on rather than making anything new. The team's read on the output was that it was a better application of that client's own brand book than the client's current site. Unprompted, the agents also asked to fix the copy. The agents had been trained deeper into the brand than the humans currently working in it. That is not a threat. That is what you're trying to build.
When this is the wrong move
I want to be honest about when not to do this. If you have one landing page to ship this quarter and you'll never ship another, do not build a context stack. The math doesn't work. The training investment pays back in volume, in consistency across many pages or many campaigns, and in the ability to hand pro-level output to someone who isn't a specialist. If your brand rules aren't written down, or they change every six weeks, an agent trained on them will be wrong by Q3, and you'll blame the agent when the problem is upstream. Write the rules first. And if you don't have someone on your team, or a partner, who genuinely knows how to train an AI agent, don't fake it. The bad version of this is worse than not doing it, because it produces confident-looking output that's quietly off-brand at scale.
Hiring an agency for this isn't always the right call either. If your team has the appetite to spend a quarter iterating on their own context stack, they should. What we've written down about how we do this, including the context artifacts and the review-gate structure, lives in our agentic marketing blueprint, and plenty of teams read it and go build their own version. That's a good outcome.
What we're doing next
At the end of the meeting I asked the team to start submitting repetitive or annoying tasks to a running friction list. That list is now how we prioritize which agent or skill gets built next. Training the system is no longer a project with a start and end date. It's a standing team workflow, the same way QA or design review used to be. One of our engineers said something in the meeting I keep coming back to: the real human work is engineering the system and the framework and the context.
The rest of it is easy. That's the shift, and it's the inversion I opened with, arriving where we've been heading the whole time: once the context is deep enough, the agent is smarter about your brand than you are, and it starts keeping you on the rails. Don't start with the agent. Start with what you'd have to write down for a very smart new hire to do the work exactly the way you'd do it. Then give that to the machine.
Frequently Asked Questions
How long does it take to train an AI agent to a useful level?
For us it took three to four months of iterating before a landing-page agent produced work we'd put in front of a client. Naive chat-to-build failed first, then off-the-shelf agents got closer but not there. The time went almost entirely into building the context stack, not into prompting.
What actually goes into the context stack?
Design tokens, a strategy document, numbered brand and build rules, a component grammar of approved components, copy voice rules, and checklists for each review gate. The agent can only use approved components and locked tokens, and when it isn't sure about something it inserts a flag-as-TODO placeholder instead of guessing.
How do you stop the agent from hallucinating?
You fence it. The agent can't reach outside the approved components, tokens, or rules. Review gates run against the numbered rules on every page, and a verification engine diffs the shipped CMS version against the approved HTML to catch any drift in translation. Hallucination isn't a model problem for us at this point, it's a context problem, and context solves it.
Do you still need designers and developers if the agents are this good?
Yes, but the work moves. The senior work is now engineering the framework, writing the rules, curating the component library, and running the review gates. The per-page execution gets fast and boring, which is what you want. One of our builders with almost no coding background shipped a real coded page into the CMS because the trained system kept them on the rails.
Where should a marketing leader start if they want to try this?
Start by writing down what your team already knows implicitly. Brand rules, voice rules, what a good page looks like, what a bad one looks like. If you can't hand a very smart new hire a document that would let them work the way you work, an agent won't be able to either. Once the document exists, the agent is the easy part.