⚡ Map the events that trigger agents
The basic flow for any automation is always the same: event → classification → agent selection → execution → validation → decision → delivery. Starting with the event avoids the common mistake of building a robot without a clear trigger.
How to read: only the cyan core is truly automatic. Classification and decisions are still governance—yours or a rule you set. Automating the core is cheap; automating the edges is where teams get hurt.
📋 Events worth automating
Clear trigger
Without it, there’s no automation
Classify
Not all events are the same
Validate
Always before deciding
Decision
Has an owner and clear criteria
🔗 Integrate with Issues, Repositories, and Pipelines
Automation needs to live where the work already happens. If the agent's result appears in a separate chat, it won't be reviewed or held accountable — and the automation dies from disuse, not defects.
✓ Integration that sticks
- ✓The result comes as pull request, with a reviewable diff
- ✓The agent has its own identity (so it can be filtered and audited)
- ✓The PR references the event that originated it
- ✓The evidence (logs, tests) is attached, not summarized
✗ Integration that dies out
- ✗Output in a chat channel nobody monitors
- ✗Push directly to the main branch
- ✗An agent using someone's personal credentials
- ✗No trace of the event that triggered the change
The PR is the surface
Where the review happens
Identity
From the agent, not you
Trace
Event → change
Evidence
Attached, not narrated
🔧 Automate CI Failure Fixes
It’s the best case to start with: the trigger is objective (the pipeline failed), the verifier already exists (CI itself), and the result is reversible (a PR you don’t have to accept).
🧪 Copyable exercise — agent that investigates a CI failure
Objective: turn a failure log into a diagnosis and evidence-backed proposal. Take a real failure from your CI and paste the prompt below into the agent with the repository open.
Contexto: o pipeline falhou. Log completo abaixo. <cole aqui o log da falha> Faça, nesta ordem: 1. identifique a falha REAL (a primeira causa, não o último erro impresso); 2. diga se é: (a) bug no código, (b) teste instável, (c) ambiente/infra, (d) dependência — e qual evidência do log sustenta isso; 3. reproduza localmente com <comando de teste> e cole a saída real; 4. só se for (a): implemente a menor correção e rode os testes de novo; 5. se for (b), (c) ou (d): NÃO corrija — descreva o problema e pare. Restrições: - não altere testes existentes; - não adicione dependências; - não faça push na branch principal; deixe tudo na branch atual.
How to verify: the classification in step 2 is what matters. If the agent called an intermittent network failure a “code bug,” your automation still can’t run unsupervised — and you just discovered that for free.
💡 Practical tip
A flaky test is automation’s silent enemy: it teaches the agent (and the team) to treat red as noise. Before automating CI fixes, eliminate or quarantine tests that fail on their own.
Root cause
Not the last error
Classify
Before fixing
Unstable
Quarantine, not retry
Proposal
PR, never direct push
📦 Handle dependencies and vulnerabilities
Dependency updates are recurring, tedious, well-defined work — ideal for early automation. What distinguishes good automation from an annoying bot is the evidence it attaches.
Read the changelog before bumping the version
The agent summarizes what changed between versions and highlights the stated breaking changes. Without that, upgrading is a gamble.
Fix the broken code, one dependency per PR
PRs with one dependency each are individually reviewable and reversible. An “update everything” PR is inherently impossible to review.
Prove it with tests and attach the output
The full test suite runs against the new version, and the actual output goes in the PR body. Without proof, the update isn’t a proposal—it’s a suggestion.
Changelog
Required reading
One per PR
Review and rollback
Proof
Actual output attached
Critical CVE
Priority, not a queue
🚨 Use Agents for Incident Analysis
In the first few minutes of an incident, the bottleneck is gathering information: logs from multiple services, recent changes, and time correlations. That’s exactly where an agent helps a lot—and mitigating on its own in production is exactly where it gets in the way.
🧭 Automated initial diagnosis
- •Collect logs for the period and group them by error type.
- •List deployments, feature flags, and migrations from the past few hours.
- •Correlate when the symptom started with the nearest change.
- •Present ranked hypotheses, each with the evidence that supports it.
- •Preserve the evidence before log rotation erases it.
⚠️ Attention
During an incident, the agent proposes—the human applies. An incorrect automatic mitigation in the middle of a crisis turns one problem into two and destroys the timeline needed for later analysis.
Collect
It’s the real bottleneck
Correlate
Symptom × change
Preserve
Before making changes
Not mitigate
Alone, in production
⚖️ Decide what to automate and what requires approval
Not every task should be fully autonomous. Changes to production, databases, infrastructure, permissions, and security always need additional controls.
The decision matrix in two questions
| reversível | irreversível
--------------------|-------------------|---------------------------
verificável | AUTOMATIZE | agente propõe, humano aplica
não verificável | agente rascunha, | NÃO AUTOMATIZE
| humano revisa |
Frequency comes later: within the "automate" quadrant, start with what happens every week.
Quick check: which of these is the best first automation for a team just getting started?
Reversible
First criterion
Verifiable
Second criterion
Frequent
Defines the order
Owner
Automation without an owner rots
📌 Module Summary
Next Module:
3.2 - AI Code Review: why the person implementing a change cannot be the one reviewing it.