Request an inviteSign in
Company2 min read

Why we started sleds

In September 2025 we set out to build a shared context and memory layer between engineers and the product people around them. Here is what we thought the problem was.

Every engineering team we had been part of lost the same thing, over and over: the context. Why a thing was built the way it was. What the product manager meant by the second sentence of the ticket. What the customer actually said. The engineer had some of it, the PM had some of it, the agent that wrote half the code had none of it, and a month later nobody had any.

In 2025 that got worse before it got better. Agents could write a feature in an afternoon, so teams wrote more features, and the amount of context that had to move between people went up with them. The code was cheap. Remembering why was not.

What we set out to build

A shared context and memory layer between engineers and the product people around them. One place where the request, the reasons, the decisions and the result lived together, that every person and every agent read from and wrote to. Not a wiki, which nobody updates, and not a tracker, which holds the what and loses the why.

The first version was exactly that: a memory that sat beside the work, filled by the conversations around it, readable by the agents doing it. We built it for ourselves first.

What we believed

  • The limit on a team's output was no longer how fast it could build. It was how much shared understanding it could keep.
  • Agents would become good enough that handing them context, not instructions, was the job.
  • The people who knew the most about what to build, the product managers, the support desk, the customers, were the farthest from where it got built.

Two of those turned out to be right. The first one was right for about six months. The next post is about that.

Where this lives. The manifesto is the current version of what we believe.