Insights
We Built an Internal AI Tool to Run Our Own Agency: What Worked and What Broke
Contents
No Time to Read It All?
Use our AI tool to get an instant, bite-sized summary of this article in seconds.
Most agencies talk about AI workflow automation as something they sell to clients. We sell it too, and we also run our own agency on it. Over the past few months we built an internal AI system that reads our inbox, drafts client replies in our own voice, keeps our Monday.com project boards updated, and helps stage the marketing content we publish. This is a plain account of what we built, what broke, and what we would tell any small business or agency thinking about doing the same thing.
Why we built an internal AI tool
Ruler runs on a small, senior team. Every hour spent retyping the same kind of email, chasing a Monday.com update, or copying a status into a report is an hour taken away from strategy, design or client work. The business case for internal AI tooling is capacity. A 15-person creative team cannot hire its way out of admin load the way a 200-person company can, so the extra hours have to come from somewhere else.
We started narrow on purpose. The first version of the system did one thing: read incoming email, summarize it, and flag which messages needed a human reply. That was a low-risk place to start, because nothing gets sent without a person approving it. Once that worked reliably, we expanded the scope step by step, first drafting replies for approval, then pulling calendar availability to propose meeting times, then syncing status into our project boards, and eventually helping stage blog posts like this one.
What our internal AI system does day to day
Our internal AI layer now handles four kinds of work.
Email triage and drafting. The system reads and classifies incoming client and prospect emails and, where it makes sense, turns them into a draft reply that matches our tone, stays short, and follows rules like "this client's contract is owned by a colleague, do not draft" or "never promise a number we have not agreed to." Every draft waits in an approval queue until a person sends it.
Project board upkeep. We run client work through Monday.com boards. The system creates items, updates statuses and posts progress notes based on what happened in a thread, so nobody has to log it after the fact.
Scheduling logic. Proposing a meeting slot means checking real calendar availability, respecting working hours, leaving buffers around existing meetings, and never offering the same slot to two different people. That sounds simple until you have tried to do it by hand across several calendars during a busy week.
Content operations. The system researches topics, drafts long-form content, and stages it for review with the metadata a publishing workflow needs (keywords, meta descriptions, images). A person still reviews and approves everything, but nobody has to assemble it from scratch.
What broke, and what we changed
Several things did not work on the first attempt.
The system offered the same meeting slot to two different contacts in the same week. Checking "what is already booked" has to cover confirmed meetings plus every calendar, every held slot, and every other pending draft that mentions a time. We had to make the "is this slot free" check stricter than felt necessary at first.
Early replies sometimes over-promised. They restated a price, committed to a timeline nobody had agreed to, or answered a question that only a specific team member could answer. We fixed this by narrowing what the system is allowed to handle, so it no longer has to judge every case. Certain topics (active pricing negotiations, credential handovers, anything a colleague already owns) now get logged for a person to handle directly, and the system drafts nothing for them.
Draft replies sometimes read as if they had been translated, especially in Greek. Getting the tone consistent took explicit examples of how we write; an instruction to "sound natural" was not enough.
All three fixes came from the same habits. Give the system a narrow, well-defined job, make risky decisions require a person, and when it makes a mistake, add a rule instead of rolling the whole thing back.
The part that surprised us
We expected the technical integration (connecting email, calendar, project boards) to be the hard part. It wasn't. The hard part was writing down all the small judgment calls a person makes without thinking: who owns which client relationship, which requests are urgent and which are routine, what tone fits a warm long-term client compared with a first-time prospect. An AI system can only work from the operating knowledge you are willing to write down, and most of our build time went into capturing it. Wiring up the APIs took far less.
What this means if you are not an AI company
You do not need to be a software company to get value from this. The businesses that benefit most from internal AI tooling have real repetitive load: inbound leads that need a fast first response, status updates that need to land in the same place every time, scheduling that eats an outsized share of someone's day. If any of that describes your operation, the return shows up as hours back on your team's calendar within weeks.
What worked for us was starting with one narrow, low-risk task, keeping a person approving anything that goes out the door, and expanding scope only after the narrow version had run clean for a while.
What we are building next
We are now building our own in-house CRM and project management software, with reporting, research and A/B testing folded in, so the AI layer that runs our internal operations becomes a tool our team and our clients can use directly. As with the first system, the aim is to give people hours back without handing them another system to babysit.