Copied to Clipboard
A strong Tester Agent reports not only what passed, but also what it could not verify:
## Tester Agent Report
Added tests:
- submitted users do not receive reminders
- users without submitted forms still receive reminders
Ran:
- php artisan test --filter=WeeklyReminderEligibilityTest ✅
Not covered:
- timezone-specific week boundaries
- users with multiple submitted forms
That "not covered" section is the valuable part, because it tells you exactly where the implementation is still unproven.
Reviewer Agent
The Reviewer Agent reads the diff like a code reviewer, and a good reviewer does not simply praise the work. It should check:
- Is the change minimal?
- Are names clear?
- Is behavior hidden in the wrong layer?
- Are tests meaningful?
- Is there duplicated logic?
- Could this break existing callers?
Example review output:
## Reviewer Agent Findings
### Concern: Week boundary depends on server timezone
The implementation uses `now()->startOfWeek()` without checking the app's configured user timezone.
Recommendation:
Use the same timezone source used by the reminder scheduler, or add a test proving this behavior.
### Positive
The change is small and keeps existing interval logic unchanged.
A Reviewer Agent is useful precisely because it creates friction, and good engineering needs friction in the right places.
A code review desk: a magnifying glass over a pull request diff, beside a checklist for Scope, Tests, Risk, and Naming.
Security Agent
The Security Agent focuses on risk, and it should be skeptical by default.
Checklist:
- authorization checks
- authentication bypass
- SQL injection
- unsafe shell execution
- secret exposure
- sensitive data logging
- insecure redirects
- dependency risk
- excessive permissions
Example prompt:
Review this diff for security risks. Do not edit files.
Return findings with severity, file, reason, and recommendation.
Example output:
## Security Agent Report
### Medium: Missing authorization check
File: app/Http/Controllers/InvoiceController.php
The new endpoint returns invoice data but does not call a policy or permission check.
Recommendation:
Add `$this->authorize('view', $invoice)` and a feature test for unauthorized access.
### Low: Log may expose customer email
File: app/Services/BillingService.php
The error log includes full request payload.
Recommendation:
Log only the invoice ID and gateway error code.
The Security Agent should usually be read-only. Security patches should go through a Developer Agent or a human, so the agent that finds a risk is not the same one that quietly rewrites the code around it.
Documentation Agent
The Documentation Agent turns implementation details into human-readable guidance. It can update:
- README
- docs folder
- API examples
- changelog
- migration notes
- release notes
Example input:
Behavior changed:
Weekly reminders are skipped when a user submitted the current weekly form.
Files changed:
- app/Services/WeeklyReminderEligibility.php
- tests/Feature/WeeklyReminderEligibilityTest.php
Example documentation update:
### Weekly Reminder Eligibility
A user is not eligible for a weekly reminder if they already submitted the
weekly check-in form for the current week.
If no form was submitted, the existing reminder interval rules still apply.
This is one of the highest-value specialized agents, because documentation is the first thing that gets forgotten when engineers are busy.
Orchestrator Agent
The Orchestrator Agent coordinates the others, and the key rule is that it should not do all the work itself. Its job is:
- split the task
- assign agents
- pass context
- enforce order
- check required outputs
- stop at approval gates
- combine final report
Example workflow:
Orchestrator
↓
Analysis Agent: find relevant files
↓
Tester Agent: create failing test
↓
Developer Agent: implement change
↓
Tester Agent: run checks
↓
Reviewer Agent: review diff
↓
Security Agent: review risks
↓
Documentation Agent: update docs
↓
Orchestrator: final PR summary
The orchestrator creates structure; the specialized agents create focused output.
An orchestration wheel: the Orchestrator at the center with six labeled spokes for Developer (Implement), Tester (Verify), Reviewer (Review), Security (Protect), Documentation (Explain), and Analysis (Discover).
How agents hand off work
Handoffs should be structured. Do not pass a vague paragraph when a typed artifact would work better.
Example handoff from Analysis Agent to Developer Agent:
{"task":"Prevent duplicate weekly reminders after form submission","relatedFiles":["app/Console/Commands/SendWeeklyReminders.php","app/Services/WeeklyReminderEligibility.php","tests/Feature/WeeklyReminderEligibilityTest.php"],"currentBehavior":"Reminder eligibility checks interval but not submitted weekly forms.","recommendedChange":"Add submitted-form guard before interval logic.","risks":["week boundary timezone behavior"]}
A typed artifact like this is easier for the next agent to use and easier for humans to inspect.
A practical agent team configuration
Here is a simple configuration example:
agents:
analysis:
role: "Findrelevantcodeandexplaincurrentbehavior"
edit: false
developer:
role: "Implementscopedcodechanges"
edit: true
requires_approval_for:
- "productioncode"
- "dependencies"
tester:
role: "Createandruntests"
edit_paths:
- "tests/**"
reviewer:
role: "Reviewcodequalityandmaintainability"
edit: false
security:
role: "Reviewsecurityandprivacyrisks"
edit: false
documentation:
role: "Updatedocsandchangelog"
edit_paths:
- "README.md"
- "docs/**"
- "CHANGELOG.md"
This setup is not complicated, and that is the point. You can start small.
Final thought
Specialized agents are not about making AI architecture fancy. They are about making AI work easier to control.
A Developer Agent implements. A Tester Agent verifies. A Reviewer Agent challenges. A Security Agent protects. A Documentation Agent explains. An Orchestrator Agent coordinates. That structure mirrors how real engineering teams already work, and that is exactly why it works.
One giant agent may look impressive in a demo. A small team of focused agents is the thing that holds up in production.
Sources used
Originally published at nazarboyko.com.