It's Friday afternoon. You're wrapping up. A teammate pings about a latency spike and needs your help investigating. You know the drill:...
For further actions, you may consider blocking this person and/or reporting abuse
Thank you for this great write up and including what to look out for. I'm super curios about Kiro Crew and am mulling over trying it but my builds are small so it may be overkill.
However, this alone would be worth the price of admission for me:
"Knowledge graph: architectural decisions, coding preferences, project context stored with vector embeddings and full-text search."
Also, you mentioned that .kiro and steering files transfer over. Is that per project?
yeah the knowledge graph is honestly the feature that sold me too ive used claude code cursor copilot all of them reset every session you spend the first 10 minutes going ok so this project uses cdk not terraform and the naming convention is.......... every single time.
to answer your question yes .kiro config is per project. the steering files live in your repo root under .kiro/ so each project gets its own rules skillsand preferences. crew then adds a persistent memory layer on top that carries across sessions for that workspace. so project A doesnt bleed into project b but within project A the agent remembers everything from last tuesday.
for small builds it might still be worth it just for the memory alone. even on a solo side project i got tired of reexplaining my folder structure.
Thanks!
Yup! Your Welcome L. Cordero
That’s exactly the part that caught my attention too. For smaller builds, full multi-agent orchestration may be more than you need, but persistent project context could still be genuinely valuable.
On the .kiro and steering files, I’d treat the transfer behavior as project-specific unless the documentation confirms otherwise. That distinction matters, especially if you work across multiple repositories.
The input-validation and output-redaction controls are useful boundaries, especially for MCP-connected agents. I’m curious about the layer before execution: how does Kiro Crew determine whether a proposed action is justified by the required evidence, applicable exceptions, and approval conditions?
For example, a tool call may be valid and permitted, but the decision behind it may still be unresolved. Do you model outcomes such as approve, deny, unresolved, and escalate explicitly, or leave that reasoning to the individual agent workflow?
it doesn't model those outcomes explicitly yet right now its deny patterns (hard block) + approval modes (trust/supervised/locked) thats it.
The scenario your describing tool call is valid but the reasoning behind it is questionable yeah thats a real gap. Today youd catch that in the audit logs after the fact not before execution. what does Judgment pack do differently here? sounds like youre building exactly this layer. Would be interested to understand how you handle the unresolved state in practice does execution pause or does it fall through to a default?
Thanks, Sarvar. Yes, that is exactly the gap Judgment Pack is trying to make explicit.
Instead of leaving the decision to each agent workflow, a pack declares the required evidence, applicable rules, exceptions, and approval or escalation conditions. For the same facts and pack version, a conforming evaluator returns the same disposition -
approve,deny,unresolved, orescalate.In practice,
unresolveddoes not fall through to execution. It returns a non-executable result with reasons such as missing required evidence or unknown facts. The workflow must then collect more evidence or request human review. Only an approved disposition proceeds to the tool.The pack can also be tested against scenarios, reviewed, improved, and versioned by authorized authors. That creates a controlled feedback loop around the organization’s judgment, rather than discovering questionable reasoning only through audit logs afterward.
A pre-execution Judgment Pack hook could be an interesting complement to Crew’s existing deny patterns and approval modes.
I've been using Kiro CLI daily for months, so Crew feels like the natural next step. The selflearning memory is what excites me most. Every AI tool ive used forgets context between sessions. You spend 10 minutes re-explaining your project every time you open a new chat.
What workflows would you automate if your agents could run unattended? I'm thinking morning PR digest, flaky test hunting, and dependency drift alerts. Would love to hear what's eating your time that Crew could handle.
Good guide, I use the Kiro editor 👍🏼
Yes it amazing tool making our super easy on daily basis 😁
The orchestrator layer is where agent projects start becoming real systems. I would look hardest at handoffs, state, retries, permissions, and observability. Those are usually the difference between a demo and something teams can operate.
Spot on. Handoffs and observability are exactly where most agent tools fall apart in practice. You can get a demo working in an afternoon, but the moment you need to trace why agent b picked up stale context from agent A youre debugging blind. crew's checkpoint or retry system and signed audit logs are what caught my attention for production use. Being able to replay a failed task from the last checkpoint instead of restarting from scratch thats the kind of thing you only appreciate after losing 20 minutes of inference time to a transient api failure.
What's your current observability setup for agent workflows? curious if youve found anything that works well for tracing multistep ai tasks.
For agent observability I like a boring stack: structured task events, checkpoint ids, tool-call evidence, handoff summaries, and one trace that links them. The key is being able to answer: what context did agent B inherit, and when did it become stale?
yeah thats the stack id run too. one thing I noticed with crew specifically the checkpoint ids carry the full context snapshot not just deltas, so when you trace back you can see exactly what state agent B started with. Makes the when did it become stale question answerable without guessing.
have you tried wiring something like this into cloudwatch or do you keep it separate?
I usually keep that trace separate from the main app logs at first. CloudWatch is fine for transport, but I want a task-native view that can answer: what context did the agent receive, what changed, and which checkpoint was replayed. Once that shape is stable, then I would mirror enough into CloudWatch for ops visibility.
thats the right sequence. get the shape stable first, then pipe into cloudwatch for the ops team. ive seen people do it the other way around (dump everything into cloudwatch day one) and end up with 50 custom metrics nobody looks at because the signal isnt clear yet.
crews SEL (signed event log) gives you that task native view out of the box. what context what changed and which checkpoint. once youre confident in the shape you could write a lambda that tails the log and pushes summary metrics to cloudwatch. havent built that yet but its on my list for next month.
Kiro Crew looks incredibly promising for AWS ecosystems! 🔥
As multi-agent orchestration scales, how are you handling runtime security between the agents? We are currently building an open-source zero-latency proxy (Aegisora) to sit in front of orchestrators like this to catch prompt injections and mask PII on the fly. Would love to explore if it could integrate smoothly with Kiro!
Persistent memory may be one of the most important pieces for moving AI agents from impressive demos to useful everyday workflows. The interesting part of Kiro Crew is not just multi-agent orchestration, but whether context can survive across sessions reliably enough for real work. I’d be especially interested in seeing how this performs on longer-running workflows.
The persistent project context is probably the part I'm most interested in here.
We've all seen the problem where an AI coding session ends and you have to spend the first few minutes reconstructing what the project is, why certain decisions were made, and what was already tried.
What I'm curious about is how you think about the boundary between memory and actual project understanding.
Remembering past interactions is one thing, but understanding how architectural decisions, dependencies, constraints, and changes relate to each other over time feels like a different problem.
Curious how far you think Crew's knowledge graph will go in that direction.
So cant we use other llm provider with kiro? or we can