Before Atono, I spent more than 20 years building xMatters, an incident management software company we grew and sold. We rebuilt the product several times – new architecture, new platform, new solutions to customers’ pain.
The code was rebuilt every time. The reasoning and the intent did not.
Customers change. Architecture changes. Teams turn over. A feature that started simple picks up exceptions because one customer needs something slightly different. Someone makes a perfectly sensible tradeoff and, five years later, the code is still enforcing it while almost nobody remembers the conversation.
We had plenty of that at xMatters.
I remember one customer with a very particular escalation setup. On weekends, certain alerts had to skip one level of the chain and go straight to a different group. There was a good operational reason for it at the time, so we built around it.
That rule survived every rewrite. Years later, it was still quietly influencing how part of the escalation engine behaved.
If you only looked at the code, it seemed odd. If you knew the customer history, it made perfect sense.
That’s the thing about mature software. The code keeps the behavior. It doesn’t always keep the story.
For most of my career, people filled that gap. A PM knew the customer history. A senior engineer remembered why a constraint existed. Someone reviewing a change would get a funny feeling and ask the one person who still knew the backstory.
It worked great, as long as we were all there to make it work.
Now we’re handing more of the work to AI.
We’ve gotten remarkably good at letting agents understand repositories. They can inspect dependencies, follow patterns, write tests and make increasingly complicated changes.
But a repository is only part of the product.
At Atono, for example, we have a screen called Everything. Inside the company, that word has a very specific meaning: it’s the centralized place where people can see work across teams, projects and workflows.
To an AI without that context, “Everything” is just an English word.
It can find every reference in the codebase and still miss what the concept means to someone using the product.
Every mature product has dozens of things like that. Usually hundreds.
The hard stories expose the gap
AI does pretty well when a task mostly explains itself.
Changing a label or updating an API call doesn’t require much institutional memory. A meaningful product change usually does.
We ran into a version of this at Atono with permissions. A story looked complete on paper: add a new action to a shared workspace view.
Engineering started working through it and someone pointed out that the action couldn’t behave the same way for every user because some workspace roles were deliberately restricted from making that change.
The rule wasn’t obscure to us. It was part of how the product already worked.
It just wasn’t in the story.
A person catches that because they’ve lived with the product. An agent only knows what you gave it.
The bigger the story, the more your AI is guessing.
The frustrating cases aren’t usually spectacular failures. The implementation makes sense. The code is clean. Maybe it even gets through review. Then somebody uses it and realizes the change is technically correct but wrong for the product.
Wrong gets caught. Almost right gets shipped.
Our own research has made this pretty hard to ignore. In a survey of 350 engineering professionals, 64% said critical product knowledge still lives in people’s heads. Only 27% said both the problem and success criteria are clear in a ticket.
That feels about right to me.
I’ve been in software for a long time and I’m not sure I’ve ever seen a product where all the important reasoning lived neatly inside the systems used to build it.
There's a reflex in this industry to hand the failure back to the user. You didn't give it enough context. Your context was stale. Your context contradicted itself. The agent couldn't see the right file.
Some of that is fair. Not all of it.
A study of 20,574 coding-agent sessions looked at the moments where developers pushed back on an agent's work. The most common failure wasn't a missing instruction. It was an instruction the agent already had and didn't follow – that accounted for nearly three quarters of explicit constraint violations, while underspecified instructions accounted for about 15% of misalignment episodes overall. In nearly a quarter of cases, the agent reported the work as finished when it wasn't.
Better context doesn't fix that. What fixes it is an agent that notices it's guessing and stops. We don't have that yet.
What we can do in the meantime is stop making it guess about things the team already decided.
Product engineering has to carry more of the product
Product engineering isn’t something AI invented.
Teams have been thinking this way for years. What has changed is how much of the software lifecycle can now happen without a person manually carrying context from one step to the next.
A lot of development still works like a relay. Product specifies something. Engineering builds it. QA checks it. A release system takes over. Analytics tells you what happened afterward.
That arrangement grew up around people, and people are very good at quietly filling in missing information.
Agents don’t have years of hallway conversations tucked away in their heads.
As they start participating in more of the process, the systems around them have to carry more of that understanding.
At Atono, we think about the work as a connected loop:
Specify → Build → Test → Release → Learn
Putting five boxes on a slide is easy. The hard part is keeping the meaning intact as work moves through them.
That’s what we mean by a product engineering platform.
The product should get better at remembering
We’ve become pretty opinionated about when product context gets created.
It has to happen while the work is happening.
If the team decides that a customer type should behave differently, that decision should stay connected to the work that came from it. If an agent is implementing a story or specification, it should have access to the terminology, rules and previous decisions that matter to that story. When the feature is released and people start using it, what happened should connect back to what the team originally meant to build.
The obvious answer is usually “better documentation,” which I’ve never found especially convincing.
I don’t know many engineers or PMs sitting around wishing they had another documentation chore.
What I want is for doing the work to leave behind better product memory.
That is how we’re building Atono.
The story is the hub. Product Knowledge can inform it. An agent can read that context while it works. Decisions stay attached. Release controls and usage can connect back afterward.
Over time, the next piece of work starts with more understanding than the last one did.
That’s the compounding part I find interesting.
You also don’t have to rip out Jira or Linear to find out whether any of this helps.
Try it with one team on meaningful agent-assisted work. Give the people and agents on that team better product context and see what changes.
Do the harder stories need less clarification? Does the agent stop making assumptions the team has to clean up later? Does the reasoning behind a decision remain available the next time somebody touches that part of the product?
If it works, move more over later. If it doesn’t, at least you didn’t spend six months on a migration project to find out.
We’re also not going to pretend we’ve finished every part of the vision. We haven’t. Some parts of the loop in Atono are much further along than others, and we’re learning as we use it ourselves.
That’s fine. I’d rather say that than draw a prettier diagram.
As agents take on longer and more complicated pieces of work, the amount of product history they need goes up. Better models help. Bigger context windows help. Better retrieval helps.
None of those things recreate a decision that disappeared two years ago.
The industry has spent an enormous amount of energy teaching AI how to understand code. That was the obvious place to start, and the progress has been incredible.
Now we have to deal with all the weird, accumulated human knowledge that makes the code a product.
That’s the part we’re working on.
Come see us at The AI Conference 2026
We’ll be at The AI Conference 2026 in San Francisco, September 30–October 1, at Innovator Booth #3.
If you’re there, come by and we’ll show you what we mean.