Projects
What I learned giving a small team their own AI
The problem
Every Wednesday, someone at the client's office had to sit down and do the same job: pull the featured listings from their website, write up the newsletter copy by hand, get the word counts right, sort the UTM tracking, and rebuild the same email template from scratch.
Nobody had flagged it as a priority because no single part of it was broken; it just quietly cost an hour a week that could have been spent on something harder to automate, and that felt worth fixing.
What I built
Monty lives in the client's existing Slack workspace and the team talk to it the same way they'd message anyone else in the channel. "Write the features for this week's newsletter" is all it takes.
From there, Monty does the work: goes into their project management tool, pulls the current listing profiles from their API, writes the copy to their house style with the right word counts, and posts it back into the thread. The team review it there and then, suggest edits conversationally, and the copy is done before anyone has had to open a second tab.
The experience was really the point rather than the automation itself. Most tools ask people to change the way they work to accommodate them, but this one met the team where they already were.
What I learned
Monty kept telling people it couldn't reach the project management tool and asking them to paste URLs instead, even though it was perfectly capable of doing it. The issue was the routing description, which is the bit the model reads before it even loads the full skill instructions. That description never mentioned the tool, so the model talked itself out of trying before it got anywhere near the part that explained what it could do.
It was a one-line fix, but the lesson was that where information appears in the context matters as much as whether it appears at all, and that's genuinely not obvious until you've been burned by it.
The original plan was that once the team approved the features, Monty would push them straight into the live draft and someone would tidy things up in the editor afterwards. I built the whole thing; the API accepted the content writes, I could read it back immediately, and everything looked fine.
Then we discovered that the moment you open the drag-and-drop editor it regenerates the email from its own internal block model and throws away anything the API wrote. The editor and the API are essentially operating on two different versions of the email, and the editor always wins. There's no warning in the documentation.
We adjusted the approach so that Monty now prepares the copy and uploads the images to the platform's file manager, which does persist, and hands the team everything they need to drop into the template themselves. It's not quite what I originally had in mind, but it's the version that actually holds up in practice, and that matters considerably more.
Square cover art can't be centre-cropped the same way a landscape photo can without clipping the artwork. I had to add a letterbox path that samples the background colour from the source image and fills the frame with that rather than defaulting to black bars. Nobody would have asked for this feature explicitly, but everyone would have noticed if it was wrong.
There are always details like this, and it's worth building time in for them.
Under the hood
Monty runs on the Claude Agent SDK in headless mode, deployed on Railway with continuous deployment from GitHub. Adding a new skill is literally just dropping a folder in the repo and pushing, and the SDK auto-discovers it on the next deploy. That fast iteration loop is what makes a project like this practical to keep improving after launch, rather than becoming something that slowly ossifies once it's out the door.
The result
What matters in the end isn't the architecture or the integrations or the workarounds, but whether the people it was built for actually find it useful and keep coming back to it. The client's team do, and that Wednesday job now takes minutes rather than an hour. They've stopped thinking about it entirely, which is exactly where you want to end up.
If you're thinking about building something similar, a tool that slots into how your team already works rather than asking them to change, I'm happy to talk through the approach.
Let's begin
Got a project? A problem? An idea that needs someone to own it? Tell us where you are and we'll take it from there.