What the **** are Agents?
Agents are AI workers that do things on their own. You give them a job, they figure out the steps, and come back with the finished work. Less “chatbot,” more “intern who actually gets stuff done.”
How agents work
Four automation patterns
Every agent workflow fits one of these four patterns. Learn them once and you can design any automation.
Parallel specialists
Divide the work, multiply the speed
Break a task into independent sub-tasks and hand each one to a specialist agent running in parallel. When they all finish, a coordinator merges results into a single deliverable.
How it works
You define a coordinator prompt that decomposes the task, spawns N agents (each with its own skill), waits for all to resolve, then stitches outputs together.
How to use it
Tell Claude to split your task into independent pieces. Each piece gets its own agent working at the same time. You review one combined result at the end instead of managing each piece yourself.
Real example
You say: "Build the settings page." Claude splits it into three parallel agents — one builds the form UI, one writes the API route, one handles the database schema. All three work simultaneously, then Claude merges them into a single working feature.
You give one instruction
Coordinator decomposes task
Specialist A
researches topic
Specialist B
reads existing work
Specialist C
checks for problems
Combined report
You review once
Event triggered
Sleep until the world changes
The agent sits dormant until an external event — a webhook, a file change, a new database row — wakes it up. It runs its checks and takes action only when needed.
How it works
An event source (GitHub webhook, file watcher, cron-triggered poll) fires a signal. The agent wakes, reads context, runs its skill chain, and branches based on findings.
How to use it
Set up a trigger — like a GitHub notification or a file change — and attach an agent to it. The agent sleeps until that trigger fires, then handles it automatically. You only get involved if something goes wrong.
Real example
A teammate opens a pull request on GitHub. The agent automatically wakes up, reads the code changes, runs your quality checklist, and posts a review comment — all before you even see the notification.
You are elsewhere
Event fires
webhook · file change · new row
Agent wakes up
Runs checks
decision point
Problem found
Alerts you + attempts fix
All clear
Logs result, goes back to sleep
Scheduled (always-on)
Set the clock, forget the rest
A cron schedule fires the agent at regular intervals. It reads from live sources, processes data, and pushes outputs to multiple destinations — no human trigger needed.
How it works
A cron expression (or platform scheduler) triggers the agent. It reads from APIs, databases, or files, processes in parallel, and delivers outputs to Slack, email, dashboards, etc.
How to use it
Pick a schedule — daily, hourly, whatever fits. The agent runs on that clock automatically, checks your systems, and sends you a summary. Like having an assistant who checks in every morning without being asked.
Real example
Every morning at 8am, the agent scans your project — checks for open issues, reviews overnight commits, flags anything that looks risky, and drops a plain English summary in your Slack channel before you start work.
Clock fires
every day at 8am
Agent reads live sources
What changed
plain English
Anything risky
flagged areas
Needs attention
open items
Summary delivered
Slack · email · dashboard
Self-correcting loop
Make, check, fix, repeat
The agent makes a change, runs a quality check against it, and if the check fails, loops back to fix the issue. It only emits output once quality passes.
How it works
The agent generates output, pipes it through a validator (tests, linter, type-checker, LLM-as-judge). If validation fails, the error is fed back as context and the agent retries — up to a configurable limit.
How to use it
Let the agent write code, then automatically test it. If the tests fail, the agent reads the error, fixes the problem, and tries again — repeating until everything passes. You get clean, working output without babysitting.
Real example
You ask Claude to add a new API endpoint. It writes the code, runs the tests, sees two failures, reads the error messages, fixes both issues, runs the tests again — they pass — and hands you a working endpoint. You never saw the intermediate mistakes.
Agent makes change
Quality check runs
result
Passes
Proceed to output
Fails
Feed error back → retry
↺Clean output delivered