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.
Thank you for the suggestion on the .kiro and steering files!
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.
this makes a lot of sense. the unresolved state not falling through to execution is the key design choice there. crews current model is basically binary allow or deny with supervised mode as a middle ground where it pauses for human approval. but theres no structured way to say i dont have enough evidence to decide yet which is what your unresolved disposition gives you. the versioned pack with scenario testing is interesting too because right now if i change a deny pattern i just hope i didnt break something. no way to regression test the judgment layer. a pre execution hook that evaluates a judgment pack before the tool fires would fill the gap between crews deny patterns and actual reasoned decision making. id be interested in seeing a minimal integration example if you have one.
let me plan some integration testing later this week, will share the results here
Yes sure this will be great. follow this series im also testing some use cases i will keep you posted. stay tune!
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!
good question. right now crew handles it with input validation rules and output redaction patterns you define in the agent config. theres also deny patterns that hard block certain tool calls. but a dedicated proxy layer sitting in front for prompt injection detection and pii masking on the fly is a different approach and probably catches things the built in rules miss especially indirect injection through tool outputs. would be curious to see how aegisora handles latency at the proxy layer since agent workflows are already sensitive to added milliseconds between steps. if its truly zero latency that could slot in nicely as a pre execution hook. happy to chat more about integration points.
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.
exactly right. persistent memory is the piece that turns these tools from cool demos into something you actually leave running overnight. in my experience the context survives cleanly for workflows under a few hours. for longer stuff like multiday tasks across sessions the knowledge graph handles it well because its not just chat history its structured relationships between decisions and code. havent stress tested it on truly multiweek workflows yet though so cant speak to how well it handles context drift at that scale. would be a good experiment to run.
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.
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.
great question and youre right these are two different problems. remembering that we discussed x last tuesday is easy thats just chat history with persistence. understanding that the decision to use dynamodb instead of rds was made because of the write throughput requirement which connects to the autoscaling policy which connects to the cost constraint thats the hard part.
crews knowledge graph stores these as relationships not just flat memories. so when you ask why did we pick dynamodb it can trace back through the reasoning chain not just say because you told me to on august 3rd. how far it goes honestly im still discovering. for straightforward architectural decisions it works well. for emergent constraints that build up over weeks of tradeoffs its still early. the vector embeddings help with fuzzy retrieval but the graph structure is what gives it the why not just the what.
That distinction between “why” and “what” is exactly what I’m interested in. The multi-week tradeoff case feels especially important — because that’s where a decision stops being an isolated memory and becomes part of the project’s evolving context. Curious to see how the graph handles those cases as the project changes over time.
yeah thats the part im actively watching too. right now for short term decisions the graph holds up well because the relationships are fresh and the context hasnt shifted. but multiweek tradeoffs are tricky because the original constraint might not even be valid anymore. like you picked a certain approach because of a deadline that already passed or a cost limit that got revised. the graph stores the relationship but doesnt automatically know when the upstream reason expired. im thinking the right pattern is something like a staleness signal where if the connected nodes havent been referenced or validated in X days it surfaces them for review instead of treating them as still true. havent seen that built yet but thats where i think this needs to go. will share what i find as i push it further on real projects.
The MeshClaw origin story is the part I trust most: kick off work, walk away, come back to something you can actually review. That last clause is where most setups with several agents quietly fail. When three of them ship overnight you do not just inherit three times the output, you inherit three times the surface you never watched being written. I would start with the PR digest and the flaky test hunter, but only if the handoff is the raw diff (or a tight list of changed files with hunks) and not a confident summary of what the agent thinks it did.
this is exactly the right instinct. three agents shipping overnight means three times the surface you didnt watch get written thats a perfect way to put it. and yeah the handoff has to be the raw diff not a summary of what the agent thinks it did. ive been burned by confident summaries that miss the one file that actually matters. for the pr digest workflow im thinking raw changed files with hunks plus a risk score based on what was touched (infra config gets flagged higher than test files). the flaky test hunter is simpler because the output is binary either it reproduced or it didnt. less room for the agent to hallucinate confidence.
So cant we use other llm provider with kiro? or we can
Yes you can kiro crew uses acp (Agent Client Protocol) underneath so the model layer is swappable out of the box it ships with claude (sonnet, haiku, opus) through the Kiro subscription but you can configure other providers.