Published for Kiro's 1st birthday week (#KiroTurns1) by the AIRE team at AWS.
When Kiro launched a year ago, our team didn't wait to see if it would stick. We opened Kiro IDE and started building.
What came out of that year is Neo — an agentic AI teammate for AWS Solutions Architects. Neo triages email, preps customer meetings, researches accounts, drafts field insights, and automates the operational grind so architects can spend their time with customers instead of with browser tabs. It was born as a single Kiro CLI agent, and today it serves roughly a thousand people across our field organization.
This post is the long version of a story we shared on LinkedIn this week. It's not a product announcement — Neo is an internal tool. It's a builder's retrospective about what it's like to build a production agentic system on a platform that's evolving underneath you, and why that turned out to be the best thing about it.
The one-sentence thesis
If you take nothing else away: the durable advantage in agentic AI is not the model — it's the harness around the model. The loops, the memory, the validation gates, the surfaces. Models get the headlines; harnesses ship the work. Kiro's first year mattered to us because it kept shipping harness primitives, and every one of them unlocked something real, usually the same week.
What Neo actually is
Before the retrospective, a quick tour — because the architecture is the story.
Neo is deliberately boring at its core: a lightweight router agent. It doesn't try to be smart about everything. Its whole job is to resolve each request to one of three targets — a typed CLI call, a specialized subagent, or a packaged workflow — then execute, merge the results, and deliver them where the user actually lives (email, chat, a local dashboard).
Around that router sit four pieces:
- Ten specialized subagents, each with its own narrow toolset: email triage, meeting prep, account research, ticket triage, documentation and diagrams, deep-expert Q&A, request drafting, knowledge search, travel lookups, and a general fallback.
- A local memory system — SQLite on the user's machine, with namespaces, full-text and semantic search, and nightly automations that compile, index, and prune what the agent learns. Less raw context, more structured recall.
- A fleet of typed CLIs as the preferred access layer to work systems, with MCP servers as the fallback. Same backends, same auth — but a compound CLI call replaces five tool round-trips, cuts tokens by an order of magnitude, and works in cron jobs and scripts where a conversation can't go.
- A local browser dashboard for task queues, review workflows, and scheduled automations.
Everything is local-first. The agent's memory, the user's data, the execution — all on the user's machine. That isn't an aesthetic choice; it's what makes an internal AI teammate deployable without moving customer data into new services.
The year, told through four primitives
Here's what stuck with us over the year. It isn't any single feature — it's the cadence. Every time Kiro shipped a new primitive, it unlocked something real in Neo, usually within days.
1. The agent format: from one router to a fleet
Early Neo was one agent with a very long prompt and too many tools. It worked, in the way demos work.
When Kiro shipped a proper agent format — a declarative spec for an agent's prompt, tools, and permissions — the design pressure reversed. Instead of one agent that knew everything, we could define ten small agents that each knew one thing, plus a router whose only skill was choosing between them.
That decomposition is what made Neo maintainable. A subagent with five tools and one job is testable. A monolith with fifty tools is a prayer.
2. Subagents + trusted delegation: 45 minutes becomes 30 seconds
The second unlock was delegation — the router spawning subagents and trusting them to run without a human approving every tool call.
The flagship workflow is the morning briefing: four subagents fan out in parallel — inbox scan, calendar and attendee research, account checks, pending-request status — and the router merges the results into one email. What used to be 45 minutes of tab-switching across six systems became about 30 seconds of wall-clock agent time.
The engineering lesson: parallel fan-out is only useful if the merge step is opinionated. The router doesn't concatenate four reports; it prioritizes the top items across domains, connects them ("this email is from the attendee in your 2pm meeting"), and formats one deliverable. The intelligence is in the merge, not the fan-out.
3. ACP: the day we realized we weren't building an app
The pivotal moment of the year was the Agent Client Protocol (ACP) landing.
The day it shipped, one integration surfaced the full Neo stack — router, subagents, memory — inside entirely new host applications. Zero new agent code. Our local dashboard drives Neo through ACP today: task queues, scheduled automations, review workflows, all speaking one protocol to the same agent that also answers in a terminal.
That's when it clicked that we weren't building an app on Kiro. We were building on a platform. The agent is the durable asset; the surface is swappable.
4. Multi-runtime: one agent spec, many surfaces
The logical endpoint of the ACP insight: because Neo's persona lives in agent specs, skills, and context files rather than in any runtime's config format, the same brain now runs on multiple harnesses. Kiro CLI stayed home base — the original and still primary runtime — but the same spec deploys to other agent hosts, and every surface shares the same local memory.
One year in, "which runtime should we bet on?" turned out to be the wrong question. The right question was "what's the smallest persona package that survives a runtime change?" Kiro's primitives let us answer it.
Five lessons from production (the part demos don't teach)
1. Route by scope, not by keywords. Neo maintains three distinct context layers — the individual's private memory, knowledge shared with a working team, and broader organizational context. Early versions routed on surface words like "shared" and "team" and got it wrong. Production routing rules name the scope and audience, not the vocabulary.
2. The generator cannot be the validator. Every write that matters in Neo passes a gate the model doesn't control: field insights go through a human review queue before anything touches the CRM; outbound email to anyone outside the company is draft-and-confirm, always — the agent shows the full draft and resolved recipients and stops. We added that guardrail after the agent conflated "draft a reply" with "send." One incident, one permanent rule, one regression test.
3. Regression-test your agent like software, because it is. Neo ships with a two-part harness: protocol-level tests that verify the router's knowledge (does it know its subagents? does it route inbox requests correctly? does it state the draft-and-confirm rule?) and non-interactive tests that execute real tool paths end-to-end. Every change to a prompt, routing rule, or skill runs the full suite before it ships. Prompts drift; assertions don't.
4. Memory is a core primitive, not a bolt-on. Neo's memory has namespaces, retention policies, nightly compilation of raw entries into narratives, and pruning of episodic data after seven days. The goal is not more context — it's better context. Structured recall beat raw context stuffing everywhere we measured it.
5. Prefer typed CLIs for compound work; keep tool calls for conversation. A single compound CLI command that joins account data, team info, and open opportunities replaces five conversational tool calls — with a fraction of the tokens and latency, plus offline and cron use. The pattern that survived the year: conversational tools for single lookups, typed CLIs for everything compound, scriptable, or scheduled.
The birthday takeaway
A year of shipping on Kiro compressed into one paragraph: start with the smallest router that can dispatch; decompose into subagents the moment a prompt does two jobs; make memory a first-class system; put validation gates the model can't bypass in front of every consequential write; and pick a platform that ships primitives fast enough that your architecture can keep absorbing them.
Demos are easy. Production is hard. Kiro kept shipping the primitives that made production possible, and we kept building on them the week they arrived.
Happy first birthday, Kiro. Here's to the next one. 🎂
Built by the AIRE (AI Readiness and Engagement) team at AWS. Neo is an internal tool for AWS field teams and is not a public product.
Top comments (0)