This Guy Treats AI Agents Like Employees

Most people are using AI agents wrong, and developer Brian Casel wants you to know it.

The typical approach goes something like this: you open your AI assistant, tell it what you need, wait for results, then repeat tomorrow. It's basically a very expensive personal assistant that requires constant supervision. Casel's approach is different—he's treating OpenClaw agents like he's running an actual company, complete with job descriptions, recurring responsibilities, and systems that let his "team" work without him hovering over every task.

The distinction matters more than it sounds. One approach keeps you as the bottleneck in your own operation. The other actually scales.

The Mental Shift From Tasks to Jobs

Casel's framework starts with a lesson he learned from managing human teams: successful hires require recurring needs, not one-off tasks. "What I learned from building real teams is that a hire only works when there's a steady flow of recurring needs that a role needs to fill," he explains in his latest video breaking down his OpenClaw setup. "Not one-off tasks that you're pulling out of thin air, but work that comes back on a predictable cadence."

Here's where AI agents break the traditional hiring equation in an interesting way. With human employees, you need enough recurring work to justify a full-time or meaningful part-time salary. Nobody's taking a job that's two tasks per week. But agent hiring costs are measured in pennies or a few dollars per task in token costs. The threshold for creating a new role drops dramatically.

You don't have to wait until you can afford a full-time hire. You can start with one or two recurring tasks and scale from there. That changes the math on delegation entirely.

For his business—which centers on research and content production—Casel identified two categories of recurring work: things he's currently doing that need to get off his plate, and things that aren't getting done at all (missed opportunities). Your categories will probably look different, and that's the point. The framework is about identifying recurring patterns, not copying someone else's specific tasks.

The Three Systems That Make Agents Actually Work

Once you've got recurring jobs defined, you hit the next problem: you become the person who has to remember to kick off every task. Open Telegram every morning, tell your agent to do the thing, wait for results, repeat tomorrow. Casel's right that this isn't delegation—it's just creating another job for yourself.

His solution involves three interconnected systems:

1. Scheduling and Dispatch
OpenClaw has a built-in cron system, but Casel found it too limited for managing multiple agents. So he built BMHQ (Builder Methods HQ)—a custom Rails app running on the same Mac Mini where OpenClaw lives. It's essentially mission control: a kanban board that breaks down tasks by agent, manages schedules (some tasks run daily, some three times a day, some monthly), and automatically dispatches work through the OpenClaw gateway.

The system also captures execution logs, which Casel rarely needs but finds invaluable when troubleshooting. "When you're getting up and running with OpenClaw, especially if you're building a sophisticated task system like this, it's really going to take a few weeks to hammer out all the bugs and all the quirks," he notes.

2. Skills as Operating Manuals
Instead of embedding detailed instructions into every task, Casel uses "skills"—markdown files (plus optional scripts and reference files) that serve as operating manuals for specific jobs. If you've used skills in Claude Code or Cursor, it's the same concept.

The advantage: when you want to improve a process, you edit one skill file instead of rewriting task instructions everywhere. Casel constantly refines these skills, often using Claude Code as his collaborator. "When you're improving your set of skills, you're literally making your team of agents better at their jobs," he says.

His skills folder includes things like content development workflows and code activity capture (which pulls activity from GitHub repos and Claude Code sessions, then documents it into his "brain" system). The skills themselves are highly personalized to his business and change frequently, which is why he's not releasing them as open source. But the structure—modular, version-controlled process documentation that both humans and agents can reference—transfers to any operation.

3. A Markdown-Based Source of Truth
The third system answers a deceptively simple question: when your agent finishes a task, where does the output go? Chat logs aren't enough. The work needs to produce artifacts you can actually use.

Casel built Brainown, a custom markdown editor and viewer that lets him and his agents share links to markdown files living in a shared Dropbox (with careful access controls so OpenClaw only sees specific folders). His agents message him on Telegram with links to these files—daily notes, content summaries, code documentation—all living as actual markdown files he can edit, reference, and build on.

"In 2026, it's actually easier and better to just build your own tools to power your business," Casel observes. He uses Claude Code for most of his custom tooling, though he could theoretically have OpenClaw agents build these systems. He considers tool-building a core part of working on his business rather than just in it.

What This Actually Looks Like in Practice

Casel currently runs four agents, organized in a separate Telegram folder from his human contacts. His general assistant, Gumbo, handles intake processing—capturing business activity and storing it in markdown files. His marketing agent runs a "content radar scan" skill that monitors announcements from companies and people he wants to follow, generating research reports that feed content development.

The task instructions themselves are remarkably simple. Instead of detailed step-by-step directions, they mostly point agents to specific skills: "use the content radar scan skill and carefully read its instructions." The complexity lives in the skill files, which can be refined independently of the task system.

It's worth noting the significant upfront investment here. Casel spent weeks in deep collaboration with Claude, iterating on processes, building custom apps, working out the infrastructure. This isn't a plug-and-play solution—it's a fundamental restructuring of how his business operates. The question is whether that restructuring creates enough leverage to justify the effort.

For Casel, who's documenting this journey for his Builder Methods community, the answer seems to be yes. But the framework he's describing—jobs not tasks, systems not supervision, skills not instructions—that's the part that might transfer even if you're not ready to build custom Rails apps.

The shift from treating AI as a chatbot to treating it as a team changes what's possible. Whether that's worth the complexity depends entirely on what you're trying to build and how much recurring work you're trying to get off your plate. But the economics of agent hiring—pennies per task instead of salaries—means the equation works differently than it did even two years ago.

The threshold for scaling just dropped. What you do with that is up to you.

—Zara Chen