The context layer and the workflows for agent-built software
Dennis Zaiser, technical founder
Software built by coding agents needs two things its code can't give it: what the agents should know, and how they should work. Most projects improvise both, one session at a time. This post defines each of them and explains why they belong together.
Two questions every agent run answers
Every time a coding agent starts a task, it answers two questions, whether anyone asked them or not. What do I know about this product? And how do I go about this task? An agent that starts from a bare repository answers the first from the code and the second from habit. It reads files until it thinks it understands, then works until it thinks it is done.
For a small fix that is fine. For a feature that touches pricing, permissions or a customer's data, “until it thinks” is the problem. Both answers should come from you, written once and kept current, not reinvented in each session by whichever agent happens to run it.
Context: what your coding agents know
Context is what your coding agents know: roadmap, boards, docs and the business logic your product follows. It is the product's intent rather than its implementation: the goals and the order they come in, the work on the boards and what each item needs, the docs that describe behaviour, the rules every change must respect, and the words the product uses for its concepts.
A context layer is the place where that knowledge lives, kept current, in a shape agents can read and people can edit. The word layer matters. It sits above the code and beside the agents. It doesn't replace the repository and it doesn't run the agents, and every agent that connects to it reads the same thing.
A context layer is not a bigger prompt. Pasting everything into every session buries the part that matters and pays for the rest in tokens. A context layer hands each task what applies to it: the rules for the area it touches, the doc section it needs, the goal it serves.
Flows: how they work
Flows are how they work: workflows with nodes, loops and your decisions. A workflow is the path a piece of work takes from idea to shipped change: plan it, build it, check it, review it, ship it, with places where it repeats and places where it stops for a person.
A workflow is a graph rather than a script. Nodes do the work. An agent node performs a task, an approval waits for a person, a condition picks a branch from the results so far, and a loop repeats its body until its checks pass. Each node declares what it reads and what it must produce, so it can't close on an empty promise.
Something starts a workflow: an item reaching a column on a board, a schedule, a webhook from your error tracker, a milestone being finished. Something carries it out: your own coding agent in your own session, or an agent started unattended on your machine or server.
Why you need both
Context without flows gives you a well-informed agent working ad hoc. It knows the rules and the goal, but nothing stops it from shipping before the checks run, nothing makes it ask before it overrides a decision, and nothing records what it did and why.
Flows without context give you pipelines running blind. The steps come in the right order, but there is nothing meaningful to read at each step. The review shows a change with no goal to judge it against, and the next run repeats the mistakes of the last.
Together they reinforce each other. Each node reads the context that applies to it and writes its results back to the same place. The plan one node produces becomes the input of the build. The approval shows the goal next to the result. The next run starts from what the last one recorded.
The tools you know, rebuilt for agents
None of this asks you to learn a new kind of tool. Roadmaps, kanban boards, docs and glossaries exist because people needed them to build software together. Agents need them too, written in a shape they can read and act on, and tied to the work they do.
So a board column can start a workflow. The order of the roadmap decides what is picked up next. A doc page, or a single section of it, can be the input of a node. A glossary is checked before an agent writes. For people the tools stay familiar. For agents they become something to work from rather than something to be told about.
Where the code stays
A context layer for agent-built software holds the record of the product, not its code. The code lives where it always lived, in your repository on your machine or your server, written by your agents. The layer holds what the code should do, what was decided along the way and what each run did.
That split is what makes the layer safe to connect to any agent, and it keeps the repository the one home of the code. It also keeps the layer independent of any single vendor: Claude Code, Codex, Cursor, Gemini CLI and Grok can all read the same context and follow the same workflows, and you can choose a different one for each task.
Where ctxflows fits
ctxflows is the context layer and the workflows for agent-built software. Context is what your coding agents know: roadmap, boards, docs and the business logic your product follows. Flows are how they work: workflows with nodes, loops and your decisions.
In ctxflows the context is your roadmap of goals and milestones, your boards, your docs and library, your terms and your datasets. The flows are workflows built from agent, approval, condition and loop nodes, started by a board column, a schedule, a webhook or a finished milestone, with a context step before each node that hands it what applies. Your agent connects over MCP and can start and follow a workflow from its own session, and the free engine runs workflows unattended on your machine or server. Your code never enters ctxflows.