1. Research & Planning Agent#

This agent doesn’t write code. It analyzes:

• Codebase structure — How is the project organized? What patterns are in use?
• Dependencies — Which packages are imported? What versions? Any known breaking changes?
• Architecture — Follows the steering file’s architecture rules
• Previous work — References learnings from prior tasks and PR feedback

It produces the task plan (the same structured plan from Day 2’s spec-driven workflow) and hands it off.

2. Code Agent#

This agent implements the actual changes. It:

• Creates new files following your project’s conventions
• Modifies existing files without breaking adjacent code
• Generates migration scripts for database changes
• Updates configuration files as needed

The code agent respects your steering file’s rules about code style, architecture, and security.

3. Verification Agent#

This agent runs after every change:

• Executes the project’s test suite
• Runs linting and type checking
• Scans for security issues (hardcoded secrets, SQL injection)
• Validates against the spec’s acceptance criteria
• Reports any failures with specific file and line references

If the verification agent finds issues, it loops back to the code agent for fixes before proceeding.

Sub-Agent Communication#

All three agents share a task spec — the same structured document from Day 2. This is the single source of truth they coordinate around. The research agent writes the plan, the code agent implements it, and the verification agent checks it — all against the same spec.

When the code agent encounters ambiguity, it consults the research agent. When the verification agent finds a failure, it sends the stack trace back to the code agent. This multi-agent architecture is more reliable than a single LLM call because each agent specializes and double-checks the others.

Environment Setup#

The agent automatically detects:

1. Dockerfile — If found, builds the full container environment
2. DevFile — Follows the specification for tools, runtimes, and dependencies
3. Project structure — If neither exists, analyzes package.json, requirements.txt, etc.

This auto-detection is critical for consistency. Your CI pipeline and your autonomous agent run in equivalent environments.

Network Controls#

Configured per task with four levels:

For the lodash upgrade example, “Common dependencies” is sufficient — the agent needs npm for the new lodash version and GitHub for PR creation.

Secrets Management#

Environment variables and secrets are configured per task:

1
{
2
  "env": {
3
    "NPM_TOKEN": "${NPM_TOKEN}",
4
    "GITHUB_TOKEN": "${GITHUB_TOKEN}"
5
  },
6
  "secrets": {
7
    "STRIPE_API_KEY": "${STRIPE_SECRET}"
8
  }
9
}

Secrets are:

• Stored encrypted at rest
• Never exposed in logs, error messages, or PR descriptions
• Injected as environment variables in the sandbox
• Scoped to a single task or session

Label-Based Assignment#

Add the kiro label to any GitHub issue:

1
# From GitHub UI: add label "kiro" to issue #42
2
# Kiro picks it up within minutes

Comment-Based Assignment#

Use /kiro in a GitHub issue comment to assign specific work:

1
/kiro Implement rate limiting on the /api/login endpoint
2
Use the existing rate-limiter middleware pattern from src/middleware/.
3
Add tests for: normal flow, exceeded limit, reset after window.

Kiro listens to all subsequent comments on the issue for:

• Clarifications to the original request
• Feedback on intermediate results
• Steering adjustments

PR Auto-Fix#

When you leave review feedback on a PR that Kiro created:

1
"Please use our standard error response format: { error: string, code: string }"

Kiro doesn’t just fix that PR. It remembers the preference and applies it to future work automatically. This is the learning mechanism — your feedback trains the agent’s understanding of your team’s standards.

Step 1: Task Definition#

In the autonomous agent chat at app.kiro.dev/agent:

“Upgrade lodash from 4.17 to 5.0 across all microservices in the saaskit-org. Handle breaking changes: _.chain removal, _.flatten signature change, _.extend behavior change. Run tests after each upgrade. Open individual PRs per service.”

Step 2: Analysis#

The agent:

1. Queries GitHub for all repos under saaskit-org containing lodash in package.json
2. Finds 15 affected services
3. Analyzes each service’s lodash usage patterns
4. Identifies which breaking changes apply to which service
5. Creates a task plan sorted by risk: low-usage services first, critical services last

Step 3: Execution#

For each service:

1. Clone → create branch → update lodash → fix breaking changes → update tests → run test suite → create PR
2. If tests fail, analyze failure and retry with different approach
3. If retry fails too, mark PR as needing human review

All 15 services processed asynchronously. Each gets its own sandbox, its own sub-agent team, its own PR.

Step 4: PR Output#

Each PR includes:

• Summary of lodash changes applied
• Breaking changes handled and how
• Test results (passed/failed with coverage delta)
• Migration notes for the team
• Any decisions that need human review

Step 5: Feedback Loop#

You review PR #1 and comment:

“For the _.chain removal — use the pipe pattern from fp/ instead of native Promise.all”

Kiro updates PR #1 and applies the same pattern to PRs #2-15 automatically. Those teams don’t need to repeat the same feedback.

Time Comparison#

Perfect Fit#

• Cross-repo refactoring — Rename a shared library, upgrade a dependency, change an API contract
• Large-scale migrations — Framework upgrades (React 18 → 19), database migrations, cloud provider changes
• Tech debt reduction — Replace deprecated APIs, remove unused code, standardize patterns across repos
• Security patching — CVE fixes across the entire organization in hours instead of weeks
• Onboarding automation — Set up new microservices following established patterns

Avoid When#

• One-line fixes — Faster to do yourself
• Exploratory work — Vibe mode in IDE is better for rapid iteration
• Highly sensitive production — Use per-file approval mode in IDE instead
• Tasks requiring real-time interaction — The agent is async by design