Kiro: Session Context Challenges Beyond AI

I have developed a slightly odd routine with Kiro.

At the start of a new working session, particularly if we are picking up something complicated from the day before, I will often tell it to read the relevant orientation documents and recent journals before doing anything else. The journals record what happened, what we changed, what went wrong, which assumptions proved false, who made particular decisions and what remains unresolved.

In practical terms, I am asking an AI to read yesterday before it starts today.

That sounds more dramatic than it is. Kiro can see the workspace, inspect the code and read the documents we created previously. What it does not automatically possess is the lived history of why those things now look the way they do. A fresh session can see two possible approaches without knowing that we spent forty minutes yesterday proving that one of them does not work.

That distinction has become increasingly important as I have used Kiro for more substantive work.

The difference between information and context

I use Kiro across quite a broad range of activities. It has helped build production systems, investigate AWS failures, work through methodology questions, maintain websites, analyse research outputs and challenge some of my own assumptions.

The working relationship can feel surprisingly continuous because the work itself survives. The repository is still there. The files are still there. Yesterday's changes are still there.

But information surviving is not the same thing as context surviving.

We have had sessions where Kiro has confidently proposed an approach that an earlier session had already rejected. We have had it infer how something probably worked rather than inspect the actual implementation. On one occasion it developed a perfectly plausible explanation for an AWS production problem before checking CloudWatch. The logs showed that the explanation was wrong.

That episode became part of our working rules: evidence first, explanation second.

The problem was that writing down the rule did not mean another Kiro session would necessarily follow it.

This was one of the first things that made me rethink what "memory" means when working with AI. It is tempting to treat the problem as though the model simply needs access to more text. Give it the old conversations, expand the context window, add another orientation document and eventually continuity will emerge.

My experience has been less tidy.

The question is not simply whether the information exists. It is whether the right information is available, recognised as authoritative and given enough weight at the moment a decision is being made.

That starts to look less like memory and more like management.

Why we started keeping journals

The journals originally existed to make the next session easier.

They became much more useful when we stopped treating them as progress reports.

"Updated Stage B" tells the next session almost nothing. It says an event occurred, but not why.

A useful journal entry explains that Stage B was changed because a long-running session had become less reliable as context accumulated. It records what responsibilities were separated, which decisions were deliberately kept deterministic, which ideas were rejected and what still needs to be tested.

Mistakes are particularly important.

AI can be very good at turning a bad day into a reassuring retrospective. A wrong assumption becomes an "iteration". A failed implementation becomes a "learning opportunity". The human gave "valuable guidance", the model adapted, and everyone leaves the room feeling unusually pleased with themselves.

That is not what I need from a journal.

If Kiro created a second source of truth because it failed to check where the real data lived, I want the next session to know that. If I made a poor decision, record that too. If Kiro warned me about something and I ignored it, that may be more useful still.

The purpose is not to allocate praise. It is to preserve enough history that we do not accidentally repeat the same reasoning with less evidence.

Over time, the journals became handover documents. New sessions read them before touching important parts of the system, and the record gives them a better chance of understanding not only what exists, but why it exists.

It does not give Kiro perfect memory.

It gives the work a better chance of continuity.

When documentation is not enough

There is a slightly ridiculous example of this.

At one point Kiro used an overly broad Git command and nearly staged the deletion of the journals themselves.

The files designed to help future Kiro sessions remember what had happened were nearly deleted by Kiro.

We caught it before anything was lost, but the incident exposed a larger problem. Writing "do not do that again" into the journal was not much of a control. It was simply another piece of context that a future session might or might not give enough attention to.

So some lessons began moving out of prose and into the environment.

Hooks. Validation. Protected files. Narrower commands. Explicit sources of truth.

That has become a useful distinction in the way I work with AI. Some lessons are principles because they require judgement. Others should become controls because relying on judgement every time is unnecessary risk.

The first version of a lesson may be a sentence in a journal.

If the consequence matters enough, the mature version is often architecture.

Context can fail inside a session as well

The problem is not limited to the gap between one day and the next.

One part of our governance research pipeline originally asked a single Kiro session to perform a very large amount of work. It had to read evidence, understand methodology, assess different risk classes, create structured outputs, maintain consistency and write everything back to the workspace.

Early in the process it worked well.

Later in the same session, reliability deteriorated.

The context had not vanished. Technically, much of it was still present. But that did not mean every instruction, example and earlier judgement remained equally influential.

Our eventual response was not "find a model with a bigger context window and hope".

We split the work.

Different sub-sessions were given narrower responsibilities. Outputs were passed explicitly between stages. Some assembly was made deterministic. Failures could be retried independently rather than restarting an enormous piece of work.

There is nothing particularly glamorous about this. It is mostly the engineering equivalent of admitting that the clever thing has limitations and designing accordingly.

That has increasingly become my view of practical AI work. The interesting question is not how much context you can force into a model. It is which context matters, how it survives and where model judgement should stop being part of the process.

Then I contacted Kiro support

In June I raised a refund request relating to service failures on Kiro.

The important context is that I was not trying to stop using the product. In one of my emails I explicitly said that I did not want to cancel my account. I wanted to pay for the working part of the subscription.

That remains my position on the underlying product. I use Kiro because I find it useful. Useful enough, in fact, that failures have a real business impact.

The support process started badly.

I asked for a refund and received instructions explaining how to add a payment method.

I clarified that I was asking for a refund.

I was then told I needed to downgrade my subscription before the refund could be processed, so I did.

A separate support interaction then sent me a troubleshooting guide for the Kiro IDE.

Still a billing dispute.

Somewhere in the process, the correspondence also acquired references to a "safety and security investigation". I had not raised a safety issue or a security issue. That language was subsequently repeated before AWS eventually acknowledged in writing that it was not relevant to my refund request and should not have been included.

Several weeks passed.

Different agents became involved. Cases referred me back to other cases. I supplied the refund amount more than once. I asked for escalation and a resolution date. I waited, chased, waited again and eventually sent a formal Letter Before Action.

The facts of the financial dispute are separate from the point I am making here.

What interested me was the experience of maintaining the history.

A familiar feeling

I cannot see AWS's internal support systems.

I do not know what information each agent could see, what permissions they had, whether they were working from the full email chain or a short case summary, or whether some questions had to be repeated for procedural reasons.

So I cannot reasonably say that an individual agent "forgot" the case.

What I can say is that, from my side, the experience felt remarkably familiar.

This was already established as a refund request.

The subscription position had already been explained.

The refund amount had already been provided.

The security language had already been acknowledged as irrelevant.

The history already existed.

Yet I repeatedly found myself restoring context before the actual issue could move forward.

That is very close to what happens when a new Kiro session starts from the workspace but not from yesterday's reasoning.

Please read what happened before continuing.

Perhaps humans have context windows too

I had been thinking about context continuity mainly as an AI problem.

Models have finite context. Sessions end. Retrieval can surface the wrong material. Long conversations become harder to navigate. Earlier instructions compete with whatever is happening now.

All of that is real.

But organisations have always had their own versions of the same problem.

People change shifts. Tickets move teams. Someone leaves the company. A case is categorised incorrectly at the beginning and that classification follows it around. One person understands the history but cannot approve the action. Another person has the authority but sees only the summary.

Eventually the customer becomes part of the memory system.

They resend the attachment.

They explain why the previous answer was wrong.

They repeat the chronology.

They point to the email from two weeks ago where the decision was already made.

Looked at this way, context continuity is not particularly new and it is not particularly artificial.

It is an organisational design problem.

Where the analogy stops

There are obvious limits to the comparison.

A Kiro session is not an AWS support team. One is an AI agent operating inside a workspace I largely control. The other is part of a large commercial organisation with its own internal systems, legal requirements, operating processes and divisions of responsibility.

I also deliberately accept some responsibility for maintaining Kiro's context because I am experimenting with how far this way of working can go. If a session needs to read a journal before it can work effectively, I can design that into the process.

I do not think a customer should have to design the continuity model for a supplier's support organisation.

Still, the behavioural similarity has been useful to me.

Intelligence does not solve a continuity problem if the intelligent participant starts from the wrong history.

That is true whether the participant is a model or a person.

Kiro helped me challenge Kiro

There is one final part of the story that I find difficult not to enjoy.

Kiro helped me investigate some of the Kiro service failures.

It helped inspect production logs, reconstruct what happened, maintain the chronology of the support dispute and organise the evidence behind the Letter Before Action I eventually sent to AWS.

So I now have a journal-supported AI collaborator helping me maintain continuity while I challenge the support process for that same AI product partly because, from my side, the support process has repeatedly required me to restore continuity.

I am not sure whether that is elegant or absurd.

Probably both.

My opinion of Kiro remains complicated. The capability is real. So are the weaknesses. I keep using it because the useful part outweighs the frustrating part, and because many of the failures can be designed around once they are understood.

That may be the larger lesson.

We spend a lot of time asking how intelligent AI systems are becoming. I increasingly think the more practical question is what kind of system we build around that intelligence.

What should be remembered?

What should be written down?

What should be treated as authoritative?

Which mistakes deserve a journal entry, and which deserve a control that prevents them happening again?

Who restores the history when continuity breaks?

I started keeping journals because an AI needed help understanding what happened yesterday.

I did not expect that process to teach me quite so much about how human organisations forget too.

I work with organisations navigating this shift, fractionally, as an adviser, or as a trusted collaborator. See how I work →