Agentic Development

Agentic development means working with an AI that acts instead of only suggesting: you give it a goal, and it plans the steps, edits files, runs commands, checks the result, and adjusts. Kiro is built entirely around that idea, which is why almost every other concept on this site exists to make your intent precise before the agent starts moving.

What is agentic development?

A chatbot answers. An agent An AI system that can take multi-step actions on its own (planning, reading and editing files, running commands) rather than only replying with text. acts. The practical difference is who does the assembling. With a chatbot you copy a snippet out of a browser tab, paste it into the right file, fix the imports, run the tests, and paste the failure back. With an agent you say what you want, and the agent does those steps itself while you watch the diff.

Kiro’s documentation describes one agent harness shared by all of its surfaces, connected through the open Agent Client Protocol Agent Client Protocol, the open interface Kiro's surfaces use to talk to the same agent harness. (ACP). That is why the IDE, the CLI, Kiro Web, the iOS app, and Kiro Crew feel like the same tool: they are different windows onto the same agent, not five separate products that happen to share a logo.

Why it exists

The autocomplete generation of AI tools had a ceiling. They were good at the line you were typing and useless at the work around it: reading three other files to understand a convention, updating a test, running the suite, noticing that the build broke. Every one of those steps still landed on you, so the tool saved keystrokes rather than time.

Agents remove the shuttling. The cost is a new kind of risk. A tool that can edit twenty files can also ruin twenty files, and it does so confidently. Kiro’s answer is not to make the agent timid but to surround it with structure: written plans (specs), permanent project knowledge (steering), scoped identities (custom agents), a permission layer, and checkpoints. Learn the loop first and the rest of the site stops looking like a pile of features.

How it works

Kiro’s “How Kiro works” documentation sets out a single turn loop, and every surface runs it:

1. Context assembly. The agent gathers what it needs: your prompt, steering files, the files you referenced, spec documents, prior conversation.
2. Model planning. The model decides what to do next and which tool to call.
3. Permission checks. The requested action is tested against your permission rules before it happens.
4. Tool execution. The tool runs: read a file, write a file, run a command, call an MCP tool.
5. Result feedback. The output goes back into the conversation, so the agent can see whether the command failed.
6. Context management. When the window fills, older history is summarized so the session can keep going.

Step 4 is worth knowing in detail, because “the agent” is really a small set of built-in tools. Every surface shares read_file and read_files, list_directory, file_search, grep_search, fs_write, fs_append, str_replace, delete_file, execute_bash, web_search, web_fetch, invoke_subagent, disclose_context, introspect, and todo_list. The IDE adds process tools (control_bash_process, get_process_output, list_processes, read_code). The CLI adds its own, including code for tree-sitter parsing across 18 languages, goal, session_settings, and tool_search.

Choosing how much freedom to give. In the IDE, Settings → Agent → Agent Autonomy (the kiroAgent.agentAutonomy setting) picks between two modes. Autopilot lets the agent work end to end, creating files, modifying code, and running commands, with everything viewable and revertible. Supervised pauses after each turn that edits files so you accept or reject each change hunk by hunk.

Checkpoints sit underneath both modes. Kiro creates one automatically on every prompt, snapshotting the files the agent changed with its built-in tools. Restoring a checkpoint puts those files and the agent’s context back and discards the chat after that point.

Common mistakes

Treating the agent like a search engine with hands. “Make it better” produces confident, plausible, wrong output, because the agent had to invent the goal you did not state. The fix: say what “better” means in one sentence, or open a spec so the goal gets written down before any code exists.

Running Autopilot on work you cannot check. Autonomy is cheap when a test suite can tell you the answer and expensive when only a careful human read can. The fix: match the mode to the verification you actually have. Supervised for a refactor of unfamiliar code, Autopilot for a change with green tests around it.

Assuming an interrupted agent stopped thinking. Closing a laptop does not stop a cloud session, and credits keep being spent. The fix: end runs deliberately, and treat unattended work as something you come back and review, not something that reviewed itself.

Confusing checkpoints with git. The fix: commit first. Use checkpoints inside a session and git between sessions.

Permissions and safety

Every action passes a permission check before it runs. Kiro’s permission model has twelve capabilities (fs_read, fs_write, shell, web_fetch, web_search, mcp, subagent, skill, power, context, diagnostics, sandbox_network) plus the meta names all, builtin, and filesystem. Each rule has an effect, and the effects are ranked: deny beats ask, which beats allow, and a deny always wins no matter which scope wrote it.

Rules live in ~/.kiro/settings/permissions.yaml for you and in ~/.kiro/workspace-roots/<hash>/permissions.yaml for a workspace, deliberately kept outside the repository. When a prompt appears you can pick Allow, Deny, Always allow, or Always deny, and persist the choice to all workspaces, this workspace, or this session. Alongside permissions, .kiroignore keeps whole paths out of the agent’s reach in the first place.

Where it fits

Agentic development is the container for everything else. Specs decide what the agent builds. Steering shapes how it thinks about your project. Hooks decide when it acts without being asked. MCP and powers extend what it can reach. Custom agents and skills define who it is and what procedures it knows. The IDE, CLI, Web, and Crew are where it happens, and cloud sessions decide whose machine runs it.

Autonomy support differs by surface. Autopilot and Supervised are IDE modes; Supervised is not available in cloud sessions. Checkpoints are an IDE feature, experimental in the CLI’s V3 sessions, and not in Web or mobile.

Learn more

• Beginner Tutorial walks through a first agent session end to end.
• Core Concepts is the map of all twelve ideas.
• Checkpoints and rewind and Compact a long session are the two recipes that keep long runs healthy.
• Set reasoning effort tunes how hard the model thinks per turn.
• Common Mistakes collects the failure modes this page only samples.