Initiatives

An initiative is for when something should be built. A fix support keeps running into, a feature a customer asked for, a change to a procedure that touches several systems.

You shape it with the agent until there’s a plan. Someone who read the plan approves it. Then people build it in slices, with their own coding agents, like Claude Code or Codex.

The request, the code and the yes in one place

Without it, a request and the facts about it live apart. The request is a ticket in a customer’s words. What the product does today is in the code. People decide how to build it in a chat, and say yes in a meeting. When someone finds something nobody knew, they change the plan quietly. When the customer asks when, someone has to go and ask an engineer.

An initiative keeps all of it together. The people who approve read one page. The people who build take their work from it, and what they can’t build as planned comes back there.

Shaped in a conversation

You start one from New initiative by saying what should change. Under the message box, you pick the topics where you worked it out, or a ticket or page from your connected tools, and the agent reads those first. Before you make one, Emargen looks for an open one with the same aim. If there is one, you open it, or say why yours is different.

We left who sees it out of the start, because that choice doesn’t belong in the chat. A new initiative is yours alone until you share it from its page.

The agent reads before it writes. It goes through the tickets and documents your organisation connected, earlier initiatives and topics, and your code. Then it asks what it couldn’t find, one question at a time, with options to pick. Its first draft of the brief appears beside the chat, with the other sections.

When the draft reads right, the agent writes the brief, checking each claim against your code. A question nobody can answer yet can go to a spike, where the agent finds out and cites what it read.

The agent proposes, you decide

You don’t type into the initiative. You tell the agent, and it writes and says what changed. It suggests how much each requirement matters, and you set it. It compares the approaches, and you choose one, with a reason for whoever wasn’t there. When two initiatives turn out to be one, or one is really two, it proposes a merge or a split. Nothing happens until you do it yourself.

Once you’ve chosen, the agent maps the approach onto your code. When you ask, it cuts the work into slices, each a step you can show working. Every change is on Changes, for everyone who can open the initiative.

A person says yes

The Kickoff sums up the plan in a few sentences and lists the checks. Some are Emargen’s, and some your workspace adds, like a tick once the customer has read the brief. Once none of them holds it back, you publish from there. Someone allowed to approve reads the Kickoff, asks in its comments if something’s unclear, and approves. No agent publishes or approves.

Built in slices

Once someone who edits it starts delivery, people’s coding agents take each slice’s tasks through Emargen and build them in your repositories. Their questions come back to the initiative. So does what they can’t build as planned, as a change request, the only way an approved plan changes. Emargen shows each slice’s progress from the work itself, so anyone who can open the initiative sees it without asking.

A support case, start to finish

Support worked out in a topic why one customer’s access requests went missing. A depot’s approver was promoted on a Friday, and six requests waited for nobody until Monday. It had happened twice before.

Someone in customer success starts an initiative and names the topic. The agent reads it, the customer’s ticket, the two old tickets and how the code routes a request. Then it asks two things. Should waiting requests follow the person, or stay with the depot? And who gets them when nobody at the depot can approve? With the answers, it writes the brief, and says what it couldn’t confirm: does the product hear at once when a role changes in the customer’s sign-in provider?

123456Full size

The agent read the support topic and the old tickets, drafted the brief, then asked two questions.

1. The first message, naming the support topic.
2. What the agent read before it wrote: the topic, the tickets and the code.
3. A question, with options to pick, and the one picked.
4. Brief. The brief the agent wrote from the answers, beside the chat.
5. Unverified. What the agent couldn’t confirm, which a spike later finds out.
6. The initiative’s sections, from Background to Changes.

It proposes the requirements, and leaves “follow the person” out, since the answer was the depot. Then two ways to build it. One moves the waiting requests when a role changes. The other works out the approver each time the inbox is read, so nothing moves and there’s no history to keep. The first rests on the open question, so the agent reads the old tickets, the provider’s documentation and the code in a spike. The product sees a role changed in its own portal at once, and one changed in the provider at the person’s next sign-in.

The owner chooses the first, has the agent slice it and publishes. The customer read the brief on a call that morning, which meets one of the workspace’s own checks. A product manager approves it, and people’s coding agents build its two slices.

12345Full size

Approved, with what was checked. Security's read was still open, and Publish didn't wait for it.

1. Approved. Who approved it, and on which day.
2. In short. The plan in a few sentences.
3. Emargen’s checks. The gaps Emargen looks for in every plan, all done here.
4. ACME’s checks. The ones the workspace adds. The customer’s read of the brief is met.
5. Security’s read, still open. Publish doesn’t wait for it.

The rest of the area

• The brief and sources. The problem and what’s true today, and what it was worked out from.
• Requirements. What must be true when it’s done, and how much each one matters.
• Approaches and spikes. The ways to build it, and what a spike finds out.
• The decomposition. The chosen approach, mapped onto your code.
• The Kickoff and approval. The page it’s published from, and who may say yes.
• Slices and tasks, delivery and change requests. How it’s built, how it’s going, and how an approved plan changes.

An initiative is shared like a topic, with one more choice. Someone who edits it shapes it as its owner does. Decisions is where you approve a Kickoff, review a merge and decide a change request.

Next

How to

• Start an initiative from a topic
• Shape an initiative
• Publish and get approval

Page by page

• The initiatives list
• An initiative’s pageits chat and its sections