Build your own AI platform when the workflow is the product: when the way your team does the work is the reason clients hire you, and no vendor sells that. Buy when the job is commodity and a subscription covers most of it. I build the internal AI platform at Tandem Interactive, a Fort Lauderdale agency, and everything below comes out of drawing that line in production.
Should an agency build or buy its AI tools?
Default to buy. That is odd advice from someone who built the in-house platform, but it is where any build-versus-buy decision should start. Vendor tools are maintained by teams. Your build is maintained by whoever wrote it, in whatever time is left after client work. The first working version is the cheap part. The real invoice arrives in year two, when models get deprecated, APIs shift under you, priorities pile up, and the tool everyone depends on needs the same care as a product.
The bar for building has to be specific, and mine has two parts. First, the workflow you are automating has to be the thing clients pay your agency for. If your process is your edge, renting a generic version of it means sanding that edge down to fit someone else’s product decisions. Second, the vendor demo has to die at the step that matters. Every tool looks good for the first 90% of a job, and agencies live in the last 10%: the odd client constraints, the judgment calls nobody documented, and the sanity check a senior person runs before a number leaves the building. When that last stretch is where your value sits and no product handles it, build.
The third trigger is custody. Client data flowing through a rotating cast of third-party AI tools is a conversation you’ll eventually have with somebody’s legal team.
| Signal | Call |
|---|---|
| The workflow is what clients pay for | Build |
| The vendor demo dies at the step that matters | Build |
| Client-data custody keeps coming up with legal | Build |
| The job is commodity and a subscription covers it | Buy |
| Nobody on the build side has ever done the job | Buy |
I spent ten years in marketing before I became an engineer, so when I built the platform I was building for a user I used to be. That closeness is the fourth trigger, and it is what makes the other three answerable, because you cannot tell from the outside which part of a workflow hurts. If nobody on the build side has ever done the job the tool serves, that is a strong argument for buying.
An internal AI platform is a promise to your own team that the boring parts of the job will get faster and the trustworthy parts will not get looser. If the tool ships a wrong number faster than a person would have, it has made things worse.
What does fail-closed AI design mean?
Fail-closed means the system degrades to silence instead of a guess. When it cannot verify something, it says so or says nothing. Fail-open fills every gap with the most plausible-sounding thing available. Language models fail open by nature, so the platform’s job is to supply the doubt the model does not have.
This matters at an agency because a hallucination ends up in a client deliverable. A made-up statistic does not die in a chat window. It goes into a deck, gets presented, survives the meeting, and becomes your agency’s claim. The plausible outputs worry me more than the absurd ones, because a plausible number rarely gets a second look at the end of a long week.
Fail-closed loses the demo every time, because “I could not verify this” sounds worse than a confident wrong answer, right up until the wrong answer reaches a client. Build it that way anyway, because you are optimizing for month six, when people have stopped double-checking the tool.
Why AI numbers need to carry uncertainty
Ask a language model the same question twice and you will get two answers, by design. That means any metric built on a stochastic system is a sample, and one sample proves nothing, no matter how good the dashboard in front of it looks.
The fix comes from basic statistics. Sample repeatedly, report rates, put a range around every number before anyone compares it to anything, and fire alerts only when the ranges separate.
What surprised me is that reports which carry their uncertainty get believed more. Sometimes the reading is “this has not moved enough to say anything yet,” and a team that has seen the system admit that will act when it reports a real move. The first time a reported drop turns out to be sampling noise, the tool loses trust that takes months to earn back.
How should AI agents be permissioned and audited?
Once an AI feature stops describing things and starts doing things, you have hired a coworker with keys. The useful principles are old security ideas:
Least privilege. An agent gets the narrowest access that still does the job, limited by the role of the person driving it. Nobody gives an intern admin rights on day one, and software that sometimes hallucinates deserves the same caution.
Deny by default. New capabilities ship locked and get opened deliberately, one person at a time, with a name attached to the call.
Everything leaves a record. Every action an agent takes should land in a log a person can read later, because at some point you will need to reconstruct what happened. Sometimes that is a client asking why something changed, and sometimes it is you at 11pm trying to work out what your own system did.
A person signs the irreversible steps. An agent cannot be the responsible party. Anything you cannot undo gets a person’s explicit approval attached to it.
The first time an automation does something technically correct but surprising, this stops being compliance homework. You want the audit trail in place before the surprise.
How do you get a team to use internal tools?
Shipping the platform is the easy half. Internal tools do not die in code review. They die on a random Tuesday when someone is under deadline and quietly goes back to the old spreadsheet, because the old spreadsheet never surprises them.
Nobody owes your tool their attention, and habit is the competitor. These are the things that moved adoption for me:
Start with one person’s worst task. Find the job one real teammate dreads and make it much better from end to end. Then let them do the marketing for you. One unprompted “you have to try this” in a team channel beats every launch announcement I have written.
Meet people where they already work. Every extra step between a teammate and your tool costs you users. The closer the tool sits to the workflow they already run, the less you have to beg.
Treat teammates like paying customers. That means onboarding, release notes, fast answers when something breaks, and a real apology when it is your fault. Treating a tool as “just internal” is how it loses the team’s trust.
Guard trust like revenue. One wrong number costs you ten right ones, and the person it burned tells everyone at lunch. Fail-closed design and ranges on every number are part of the adoption strategy, because people come back to tools that have never lied to them.
Rules I’d give anyone doing this
- Buy the commodity and build the differentiator. Re-ask every quarter; the vendor market keeps moving.
- The maintenance budget is the real budget. Price year two before you write week one.
- Fail closed. A visible gap is better than a confident guess.
- No bare numbers. Every metric ships with its range, and alerts require the ranges to separate.
- Agents get the least access that does the job, and every action leaves a receipt.
- A person signs every irreversible step. Software cannot be the responsible party.
- Ship to one enthusiastic user before you ship to everyone.
- Run it like a product, because to your team, that’s what it is.
FAQ
Should a marketing agency build its own AI platform?
Usually not. Buy for commodity jobs and spend the savings on your service. Build when the workflow is your edge and vendor tools keep failing at the step that matters, or when client data custody makes a long list of third parties a hard conversation with legal.
Can one developer really build and run an internal AI platform?
Yes, with tight scope and a preference for boring choices. The platform has to be maintained while models churn and priorities shift, and maintenance costs more than the writing. I had been building my own tools for years before this one, from trained models to desktop apps, and the habit that mattered most was saying no to features I would have enjoyed writing.
What does fail-closed mean in AI product design?
When the system can’t verify a claim, it declines to make one. Missing data stays visibly missing instead of getting papered over with a plausible guess.
How do you keep AI agents safe in client work?
Give them the minimum access the task requires, gate capabilities by role, require human approval for anything irreversible, and log every action so you can reconstruct it later. If a feature can act on the world instead of describing it, treat it like a new hire with production access.
How do you know an internal tool is working?
Watch whether people come back next week without being reminded. Praise costs nothing, and retention has to be earned. The clearest version of that test is what the team reaches for when a deadline hits.