AI agents are only useful when they touch real systems

At Monsoonfish I build internal AI tooling. The first thing anyone builds in this space is the obvious one: a chat shell and a library of prompts. I built that too. It’s useful, but it’s also the easiest part to copy, and it’s hard to point at anything specific it changes.

The tools that earn their keep do one job end to end, against real systems.

Two examples

Pre-call sales briefs. Before a discovery call, someone has to read the prospect’s website, the stakeholder’s LinkedIn and recent news, then turn it into something useful. That’s now a workflow: enrich the company, pull the stakeholder’s profile, look for growth signals, map competitors and industry trends, translate it into UX and UI opportunities and discovery questions, and drop a formatted brief into Gmail as a draft. A person reviews and edits it; they don’t assemble it.

Weekly client news digest. A roster of clients, a log of news about each one, and a weekly run that compiles an HTML digest, emails it, and clears what it sent so nothing repeats. Boring plumbing, and that’s the point: it happens every week without anyone remembering to do it.

What made them work

• A defined input and a defined output. “Company and LinkedIn URL in, brief in your drafts out” is something you can test and trust. “Ask the AI about a client” isn’t.
• Real integrations. The model is one step. Most of the work is getting data in and out: scrapers, email, files, schedules.
• A human checkpoint where it matters. The brief lands as a draft, not a sent email.
• Safe to rerun. The digest tracks what it has already sent. Anything that runs on a schedule has to be idempotent.

Where I’d put the effort next time

Less on the prompt catalogue and the chat UI, more on encoded workflows. A workflow that knows your tools, your data and your output format is the part that’s actually yours.