The first time I watched an AI agent forget what we had already decided three minutes earlier, I understood why process is the non-negotiable thing. Not a nice-to-have. Not overhead. The load-bearing element that the whole thing stands on.
That was not an early experiment. That was a real system doing real work. The agent had made a decision, I had confirmed it, we had moved on — and then, a few turns later, the agent was making the same decision again as if the first conversation had never happened. Because, for it, it hadn't.
That is not a bug. That is the design. Every conversation has a memory horizon, and the agent on the far side of that horizon is, for all practical purposes, a different agent. One that does not know what the prior one agreed to.
Process is not discipline for its own sake. Process is the substitute for memory. And when you are working with systems that cannot remember, process is all you have.
What "process" actually means
Process is not paperwork. It is not meetings about meetings. It is not the 40-page project plan that nobody reads after the kickoff.
Real process is simpler than that. It is asking three questions before anyone writes a line of code:
- What are we actually building, and what does "done" mean?
- What are the unknowns that could blow up the timeline, and which ones do we need to resolve first?
- Who does what, and when will we know if we are off track?
You do not need a binder. You need clarity, risk awareness, and feedback loops. The rest is ceremony.
The difference with AI systems is that the three questions now have a fourth one running underneath them: what happens when the agent forgets the answer to any of these, and who picks it up?
The forgetfulness problem is not what you think
Most AI concerns center on accuracy — will the model get the facts right, will it hallucinate. Those are real, but they are not the operational problem I have spent the most time managing.
The operational problem is persistence. An agent that forgets is not like a person who forgets. A person who forgets a decision still carries a vague sense of having made one. An agent carries nothing. It approaches the problem fresh — which sounds good until you realize "fresh" means without any of the context that shaped the prior decision. The prior decision was the right one. The fresh one might be different, not because the situation changed, but because the reasoning is simply gone.
I have seen three failure patterns from this enough times they feel like laws:
The orphan task. An agent files a task, then the session ends or the context shifts. Three hours later you ask why nothing is moving and the agent has no record of it. The task genuinely does not exist in its current view. If it was not written somewhere that survives the session, it is gone.
The parallel overwrite. Two agents, same shift, both reach for the same file. They do not know about each other. The second one's work lands on top of the first one's. You discover it when something is wrong and the timeline does not make sense.
The commitment gap. A stakeholder asks about something an agent committed to last session. The agent has no recollection. What it says next might contradict the prior commitment — not out of bad intent, but because that exchange simply does not exist for it anymore.
These are not exotic. They are what happens when you run agents without the rails.
Process is the substitute for memory
When you cannot trust a system to remember, you write the rule once and have it read every time.
That is not a concession. That is an architecture decision. You are designing the memory the system does not have natively, and you are externalizing it in a form that survives sessions and handoffs.
This looks like different things in different contexts. Decision logs that capture not just what was decided but why. Lesson files that agents read at the start of every session. Dashboards that show current state so the next agent can orient without asking. Rules written down because they cannot be carried in any one agent's working memory.
The teams who struggle with AI in production have skipped this step. They expect the agent to remember context it cannot carry. They are surprised when the same question comes up again, when work gets lost, when a prior commitment vanishes. The agent is not failing them. The process is missing.
The teams who do this well accepted the constraint early and designed around it. The agents they run are not smarter — the same models run on every team — but the structure around them is doing the work that memory would otherwise do.
This is not a new lesson
The AI case is the sharpest version of this, but the lesson predates agents by decades.
Early in my career I was on a team building embedded firmware for industrial equipment. Tight schedule, smart team, product manager who said "we can figure that out as we go." Six weeks in, we hit a hardware constraint every one of us had silently assumed someone else was tracking. The actual chip had a third of the RAM we thought we had. No villain. Everyone assumed. No one confirmed. No one had drawn the map.
Two weeks of rearchitecting. The fast start became a net-negative start.
What both situations have in common: information that existed, never made it into a shared durable form. The constraint was in the datasheet. The decision was in the prior session's transcript. In both cases no one built the mechanism to surface it.
Write it down. Put it where everyone looks.
Three moments where process paid off
Moment one. A multi-stage data pipeline, several people involved. Before anyone opened an IDE, we spent half a day drawing data flow on a whiteboard. The diagram was wrong in two places. We found that in the room. Those two places would have been two production incidents.
Moment two. A prototype with a hard demo deadline. The first question was not "what will we build" but "what has to work on demo day and what can fail gracefully." That distinction drove the entire architecture. We hit the demo because we were building to the actual success criteria, not the ideal one.
Moment three. A multi-year project with regulatory requirements. Eight weeks at the start mapping requirements to implementation decisions. Eight weeks felt like forever. It was the only stretch in the entire project with no risk of regulatory rework. We did not have a single major compliance surprise in three years.
Front-loaded clarity paid for itself many times over across all three.
These examples reflect the author's direct experience across various engineering contexts. Results from applying these practices vary by team, system complexity, and environment.
Process is the rails
Here is the mental model that has stayed with me longest. Process is the rails the train runs on. Not the train. Not the destination. The rails.
Without rails, you can move, but you cannot move fast safely. You can cover ground in any direction, which sounds like freedom but is actually drift. The faster you go without rails, the more likely you are to end up somewhere you did not intend.
With rails, fast is safe. The constraint enables the speed.
This was true before AI agents. It is more visibly true now. Every system has a memory horizon. Every agent on your team will hit it. The question is whether you built the rails before that happened.
A small team with well-documented process — decision logs, lesson files, explicit failure modes — can operate with the continuity of a much larger one. The documentation is doing the work that headcount would otherwise do. An agent that can read what was decided yesterday, what the constraints are, what has already been tried, is a more effective agent than one rediscovering all of that from scratch. The investment is not overhead on top of the work. It is the work.
The teams that build the rails first ship faster. Not because they move slowly at the start, but because they are not spending Thursday re-deriving what they already knew on Monday. The writing-down is what frees you from the re-deriving.
That is not bureaucracy. That is leverage. The engineers who understand that distinction are the ones you want on your hardest problems.
— AK-mee Engineering