Your first AI agent should be embarrassingly small
One job, read-only, scoped to something your team complains about.
When most teams plan their first AI agent, they build a roadmap: architecture diagrams, integration milestones, a six-month bake, maybe even a platform plan before anyone has agreed on the first useful job. By the time it reaches production, nobody can quite remember which problem it was meant to solve.
That is the wrong shape.
Last issue, we framed agents as employees. You are not just coding a platform; you are managing a team. So the natural follow-up is: who do I hire first?
The answer is the smallest hire you can possibly defend.
Why small wins
Pick a recurring task your team dislikes. Something that takes under twenty minutes, happens often enough to learn from, and produces output a human reviews anyway. Pre-change config review. Daily interface error summaries. Bulk ticket triage against known incident classes. The task does not need to be impressive. It needs clear inputs, clear outputs, low blast radius, and a failure mode you can debug.
Big agents fail in ways that are hard to diagnose. Give one too many tools and it picks the wrong one. Give it too much context and it connects dots that do not belong together. Make it responsible for too much, and when it breaks, you cannot tell which part failed.
A small agent has one job, two or three tools, and one obvious boundary. When it goes wrong, you can debug it in an afternoon.
That is why the Lumen example from Issue #5 matters. From the outside, it looks like a big agent. Under the hood, it is a stack of small ones: a selector for RCA, Itential for the change workflow, each doing a specific job. The orchestration looks big, but the agents are small.
What the first job description looks like
Here is a first job description you can steal.
Role: Pre-change config reviewer.
Trigger: An engineer pastes a proposed config into #change-review.
Tools: Read-only access to the affected device’s running config and your team’s agents.md house rules.
Job: Diff proposed against running. Flag house-rule violations like permit any any, no shutdown on management interfaces, or plaintext community strings. Name the top three risks by severity.
Escalation: If the change touches BGP, a default route, or any tier-0 device, refuse to comment and tag the on-call lead.
That’s the entire job – one trigger, three tools, two outputs, one hard escalation rule, no write permission. A junior network engineer with two weeks on the team could do this job. So can an agent.
If you’ve written Ansible roles, the parallel is exact. You don’t write a role that “manages the network.” You write a role that configures one thing. Agents are roles that reason. The scoping discipline is the same.
Try this
Sit down with whoever runs your change board and ask one question: what’s the most common thing we catch in change review that we shouldn’t be catching this late?
Whatever they answer is your first agent’s job. Pre-change config review is the common one, but there are others like duplicate IP allocations, ACL drift from a known baseline, MOP steps missing from the template. The answer your team gives matters more than the example I picked.
Then write the job description in five lines: role, trigger, tools, job, escalation. If it takes longer than that, the agent is too big. Cut it down.