For most of my career, getting a new tool in marketing looked like this: write a requirements document, wait for an IT slot, wait for a budget, get something six months later that almost does what you needed. Or buy a SaaS product that does 80% of it and makes the remaining 20% impossible.
A month ago we tried something else. We started what we call the Lab: an internal portal where the marketing and sales teams build their own tools with AI coding agents. None of us are developers. I know basic HTML and CSS; my colleagues know about as much.
Four weeks in, the Lab has a daily chat quality report, a documentation gap finder, a market metrics page, a watch list for customer tickets that went quiet, a social media analyser, and a coaching tool for our seminar venue. Most of these took a day or two to get to a first useful version.
This post is about how that works, and why the most important ingredient is not the AI model.
The agent is the easy part
Modern coding agents are very good at writing code. That's not the bottleneck anymore. The bottleneck is that the agent knows nothing about your business. It doesn't know what a "qualified lead" means in your company, which CRM field holds the partner tier, why the Instagram numbers from last quarter look strange, or that your support team closes tickets in a particular way.
Give an agent a vague task and no context, and you get a generic dashboard that looks great and answers the wrong question. Give it the right context, and it builds something that feels like it was made by someone who has worked with you for years.
So the real work in the Lab is not prompting. It's building context.
Three kinds of context
1. What we know: plain Markdown files.
Everything the agents need to understand lives as text files. I keep my own knowledge in an Obsidian vault: who we are, how we talk about our products, brand guidelines written for AI agents instead of designers, definitions of our metrics. Meeting summaries flow into the vault automatically every evening.
Every project repository has one entry file, AGENTS.md, that every agent reads first, whether it's Claude Code, Codex or something else. Next to it is a docs/ folder with decisions and lessons, each with a date and a reason. When an agent or a human learns something non-obvious, it gets written there. Not in a chat. Not in one tool's memory. In the repo, where the next agent will find it.
One rule turned out to matter a lot: every definition lives in exactly one place. When I cleaned up my vault in August, I found our brand colours defined in six places and one process described in nine. Agents will happily pick whichever version they find first.
2. What's happening: live connections to our systems.
Context also means data. Through MCP servers (the "USB ports" that let AI agents talk to other software) and APIs, the agents can read our CRM, our help desk, our live chat, our social media analytics and our product database. A tool that shows "active partners per market" doesn't use an export from last month. It queries the CRM when it runs.
That's also how one of our most useful pages came about. The same metric was circulating in slides with three different definitions. Now there's one definition, written down once, and the tool calculates it live. The discussion moved from "whose number is right" to "what do we do about it".
3. What went wrong: lessons written into the tools.
Every skill and every tool carries its own list of traps. For example: "never let an AI sub-agent pull tickets from the help desk, the filters get lost and you get a million results instead of a few hundred." These notes look boring. They're the reason the second run of a tool is better than the first.
What we've actually built
A few examples, to make this concrete:
- Chat reports. Every live chat from the day before is read and graded by an AI: was it answered, how long did the customer wait, was a sales opportunity missed, was the customer sent away too early. The full transcript sits next to the grade, so anyone can check.
- Documentation gaps. Closed support tickets are compared with our public knowledge base. Whatever support had to explain in writing is probably missing from the docs. The tool proposes the text to add.
- Social analyser. KPIs across our brand accounts, sentiment for every comment and DM, a list of people still waiting for an answer, and content ideas that link back to the real posts and comments they came from. A marketing colleague built most of it, not me.
- Ticket watch. Open tickets where a customer is waiting and nobody has replied in days.
- Venue coaching. Enquiries for our seminar venue that didn't turn into bookings, why, and what they would have been worth.
None of these are sophisticated software. They are small, specific, and built by the people who use them. That's the point.
Reconstructed view with made-up data: the real tool looks like this, but every name and number here is invented.
How teams stay independent (from IT, and from each other)
Each team gets its own zone in the portal: its own small app, its own path, its own deploy. If marketing breaks something, it breaks marketing's zone, not the whole portal. A new colleague gets an invitation and a "copy prompt" button. The prompt tells their own AI agent to clone the project, read AGENTS.md and work through the onboarding checklist. The knowledge stays in the repo; the prompt only points there.
Everything runs on Cloudflare with a login in front, so nothing is public and nobody had to build a login system. Viewers just need a company email address.
We looked at the alternatives. A BI tool with per-user pricing and no way to enter data. A platform product for multi-tenant apps that cost more than it was worth for three teams. Separate repositories per team. We ended up with the simplest option that works: one repository, several zones, agreement instead of enforcement.
Is this a threat to IT?
No. IT still runs the systems of record, security and everything that has to be rock-solid. What changes is the long tail: the hundreds of small reports, checks and helpers that were never important enough for an IT project but that make a real difference to a marketing team's week.
For those, the old answer was "live without it" or "build it in Excel". The new answer is: build it yourself, and give your agent the context it needs.
Where to start
If you want to try this in your team:
- Write down what you know. Start with one Markdown file: who you are, what your metrics mean, what your tone of voice is. Keep every definition in one place.
- Connect one system. Pick the one you look at most (CRM, help desk, social analytics) and connect it through an MCP server or API.
- Build one small tool for one real question. Not a dashboard. A question, like "which customers are waiting for an answer right now?"
- Write down what went wrong, with a date. That file will become your most valuable asset.
The tools are the visible part. The context is what you're really building.
Reconstructed view with made-up data: the real tool looks like this, but every name and number here is invented.
No comments yet