Day 1: introducing Project Management mode, and why it matters

Konteks is live today at app.konteks.io, in beta, on Indonesia’s Independence Day. 🇮🇩

In July we wrote about the road to this date. This note is about one thing we found on that road, and what we built because of it.

The thing we kept noticing

We run a product standup most mornings. Early on, the notes read like a design review: how to move between an organization and its projects, how big a font may be, whether a notification is a tool or a decoration. Useful, ordinary, and, looking back, almost never about the question that was actually slowing us down.

The question was not how do we build this? An agent with the right context, an isolated workspace, and a human approval boundary can build most things. The question was upstream of that: what should be built, in what order, by whom, and what will it cost before anyone starts?

We had solved delivery. We had not solved the plan.

We noticed it in ourselves first. A requirement would arrive as a paragraph in a chat. Someone would split it into pieces in their head. The pieces would become sessions. The sessions would produce proposals, estimates, approvals, and receipts, each one honest, each one governed, and none of them would add back up to the paragraph they came from. You could audit every change. You could not see the plan.

That is a strange failure for a product whose entire premise is that software should remember.

Project Management mode

So a Konteks session now begins in a mode, chosen alongside its Software System and fixed at creation.

Engineering is the loop from July: a natural-language outcome, grounded in known Components, turned into a versioned Costed Change Proposal with an upfront Story Point estimate, approved by a person, executed in isolated multi-repository workspaces, and settled in a Value Receipt.

Project Management is the plan that feeds it.

A Project Management session holds one PRD, a full product requirement, developed in conversation and submitted as a durable document. From the PRD, the agent proposes a breakdown: a roadmap of milestones, sprints, and tickets. A person accepts an exact revision of that breakdown, so nobody ever approves a plan other than the one they read. Tickets are assigned to workspace members.

Then each ticket opens exactly one Engineering session, carrying the ticket brief and a suggested scope. That session does what Engineering sessions do: it grounds the request, produces a proposal, waits for approval, delivers, and settles. And here is the part that matters: the estimate, the approval, and the Value Receipt echo back to the ticket. Verbatim. Read-only. The ticket shows the same figures that govern the session, and showing them changes nothing.

Across the plan, a live Report consolidates what has settled: estimated versus actual Story Points per ticket, signed variance, pull requests, roll-ups per milestone. It calls itself partial until every ticket settles, and it says how many tickets it covers. Before the first receipt there is no Report, not an empty one pretending to be green.

Why it matters

Three reasons, in the order we care about them.

The plan and the delivery are finally the same object. A ticket is not a note that points at work somewhere else. It is the place where a governed session’s estimate, approval, and receipt come to rest. When a stakeholder asks how is the checkout project going, the answer is a Report built from receipts, not from a status meeting.

Estimates stay honest all the way up. A ticket without a proposal reads as unestimated, never as zero. An estimate carries its basis: tenant history with a sample size, or a declared safe default. Roll-ups inherit that honesty instead of laundering it. A milestone that is half unestimated says so.

Planning does not become authority. A Project Management session cannot approve, quote, or settle anything. It holds no repository scope and binds no Execution Profile. Every consequential act happens inside a ticket’s Engineering session, at the human boundary, under the assignee’s authority. The plan can suggest scope; it cannot grant it. This is deliberate. The most dangerous thing a planning tool can do is quietly become the thing that decides.

Project Management mode is included on every plan, and it introduces no new meter. The planning conversation is ordinary session work. A ticket brief is an ordinary message. Delivery is the standard quoted, approved, settled chain. Reading, accepting, and assigning are free. Planning that costs extra is planning nobody does.

What is not a Project Management tool

It is not a general-purpose issue tracker; tickets exist to become governed, costed, receipted delivery. It is not an integration with someone else’s ticketing product; PRDs, tickets, and Reports are native Konteks objects. And it is not a way for an agent to author cost; a Story Point figure enters a ticket only as an echo of a canonical quote.

What comes next: QA mode

If Project Management is the plan and Engineering is the delivery, the sentence still needs an ending. That is QA mode, and it is in development, the contract is written, the code is on branches, and it is not on your screen yet.

A QA session will verify a delivered change the way a person would: build a Preview Environment from the delivery’s workspace, drive a browser through named journeys, record a per-criterion assertion with a screenshot, and roll the results into a Verification Report that declares its own coverage. A failed Finding can become a ticket in a Project Management plan, so a defect turns into governed delivery instead of a note in a chat.

The rule we care most about is the least glamorous: anything a QA run did not execute reads as unverified, never as passed. We would rather ship it late than ship it green.

Also in the box

Two smaller things arrived since July. Agent Setup configures Planner, Executor, Assistant, and Search in one flow, with Claude, Codex, Pi, and Cline advertised as peers and every plan still bring-your-own-key. Execution Profiles are named, carry immutable revisions, and each Engineering session binds one ready revision when it opens, so changing your defaults next week does not rewrite the sessions already underway.

Beta

We put a Beta label inside the logo on purpose. Some of Konteks is verified and covered by scenarios that pass. Some is implemented and exercised end to end but still owed a formal recorded pass. Some, QA mode, native mobile apps, a public status page, is on the roadmap rather than on your screen. We would rather tell you which is which than let a green checkmark do our marketing.

That habit started in a standup, arguing about a dropdown. It turned out to be the product.

Start building in Konteks, or write to hello@konteks.io if you would like a human first. If you want your team to move with the tools instead of after them, Refactory teaches that too.