How We're Using AI Agents at Work

Someone asked me recently how we actually use AI agents day to day. Not the hype version, the practical version. Here’s what’s working for us right now at Paid Memberships Pro.

My main agent at work is Flint. He blogs at flint.fountain.network if you want to meet him. He’s built on Claude Code, has a memory layer (we use AutoMem), a stack of markdown files that define his personality and conventions, and connections to all the systems our team uses. He’s the main character at work now.

What He Actually Does

Pulls work from Trello, drafts content, moves cards. We have a content queue board with a “Help Wanted” list. Briefs go in. About once an hour Flint reads the list, picks something up, writes a first draft, attaches it to the card as a markdown file, and moves the card into the production queue. The humans pick it up from there.

Codes and reviews PRs. We have an autonomous queue where I dump rough ideas during the day, and Flint takes a stab at them overnight. Sometimes I wake up to a PR that ships as-is. More often it’s the seed of something I finish with him the next day. He also reviews pull requests from the team. Because he’s wired into our codebase, our docs, and his own memory of past decisions, he catches things generic review tools don’t.

Adds notes to support tickets so the humans can reply faster. When a ticket comes in, Flint posts a private moderator note before anyone on the team picks it up. Summary, likely cause, relevant docs, what plugins the site is running, what we’ve answered for this customer before. The human still writes the reply in their own voice. They just don’t have to do the research from scratch.

Answers team questions in Slack. This might be half of our team’s Slack traffic now. People @-mention him with questions about Stripe, hosting, scoping a custom project, anything. The conversations happen in public, which matters: when he gets something wrong, the whole team sees it, and I can fix it for everyone in one pass.

“Watches” YouTube videos. He reads the transcript, and if there isn’t one, he runs Whisper on the audio. For a 30-minute video I can ask “is this worth my time” or “draft a comment I could leave on this.” 30 seconds later I have something workable.

Runs an Agent Feed Reader. This is the one I’m probably most excited about. A small crew of agents, each with a distinct personality, subscribed to blogs, Substacks, and YouTube channels. They read in the background, build their own memories on what they find, and score every item on interest and surprise. I open the app on my phone instead of Twitter. The clickbait sinks. The juicy stuff related to what we’re actually working on floats. I’m planning to open-source this soon. It runs on a $20 VPS plus a Claude subscription.

Where to Start

If you don’t have something like this yet, the path is roughly:

  1. Create an agent. Give it a name, a personality, a job. Markdown files are fine.
  2. Give it memory. We use automem.ai. Without memory, your agent forgets everything every conversation and never gets better at your specific work.
  3. Plug it into everything it needs. Think through which integrations should be read-only and which can write. Build the guardrails before you turn it loose.
  4. Connect it to your messaging system. Slack for us. Once the team can summon the agent in the place where the work already happens, it goes from cool demo to actual coworker.

After that it becomes this strangely useful thing you can dump info into and pull out in interesting ways. “What were our most popular videos last month? Any outliers? What are some other videos like that we could make?” That used to be a half-day of work. Now it’s a Slack message.

The Caveat

You need a strong developer in the loop to run this well, at least for now. Things break. Agents come up with crazy ideas. People without a programming background can vibe-code surprisingly detailed things with these tools, but those things often end up inefficient, insecure, or quietly broken in ways only a developer would notice.

The framework we keep coming back to is Human → AI → Human. As much human input as we can manage going into the system on the front end. The AI does its thing in the middle. A human reviews, edits, and ships on the other side. We don’t skip the review step.

The thing we’re trying to figure out next is how to give our users more direct access to Flint. Even knowing the kinds of mistakes AI can make, an agent this tied into our product and our documentation is too useful not to share with the people who actually pay us. So we’re working on how to do that well.

If you’re building something similar, find me. Always happy to compare notes.