Blog

Why every request goes into Kore before it becomes code

A chat message disappears. A decision made on a call disappears. We built Kore so that nothing important depends on anyone's memory — not ours, and not the AI's.

Picture the simplest request in the world: “change the color of the buy button”. It arrives on a Tuesday, by message. On Thursday, someone asks why the button changed. On Friday, someone else wants the old color back, because the client had said in a meeting that green was the brand color.

Nobody made a mistake. The request just didn’t live anywhere.

A core, not another tool

Kore is the system we built to run Kabran. It isn’t a task manager with a different name: it is where work, knowledge, clients and code live together.

  • Work: every request becomes an issue, with what needs to be true for it to be done.
  • Knowledge: every decision becomes a document, with the context and what was turned down.
  • Clients: proposals, meetings and replies stay linked to the project they belong to.
  • Code: every repository knows which product it belongs to and which issue each change closes.

The value isn’t in any single part. It is in the links between them.

Why AI needs this more than we do

An AI agent starts every task with no memory of the previous one. That is a limitation — and, used well, a virtue. It carries no bad habits, never “thinks it remembers”, never confuses project A with project B.

But it only works if everything it needs to know is written somewhere it can read. When an agent picks up an issue in Kore, it receives the request, the acceptance criteria, the linked decisions and the right repository. It doesn’t need to guess. It doesn’t need to ask what has already been answered.

What isn’t written doesn’t exist — not for the person who joins tomorrow, and not for the agent that starts now.

The path of a request

In practice, a request always travels the same path:

  1. it arrives through any channel and is recorded as an issue, with its definition of done;
  2. if it involves a business choice, a person makes the choice and it is recorded as a decision;
  3. the issue is dispatched to an agent, who works inside the house standards;
  4. the result goes through an independent review before it is merged;
  5. the issue closes when the effect exists, not when the code was written.

It sounds like bureaucracy. It is the opposite: it is what allows a lot to happen at the same time without anyone having to hold it all in their head.

What the client gets out of it

When you ask “why is this like that?”, the answer exists, with a date and a reason. When you want to know where your project stands, it doesn’t depend on someone remembering to send an update. And when the team changes — or the agent changes, or the model changes — your project doesn’t lose its memory along with it.

Changing the button color is still a simple request. It just has an address now.

Written by Kabran