What to build: behavior, architecture, contracts, and scope.
GoalScopeArchitectureContractsNon-goals
Learn
What is agent-native development?
Agent-native development is a way of building software where coding agents are first-class participants, not side conversations. Work flows through a reviewable loop — intent becomes a proposal, humans and agents review it, the plan becomes ordered tasks, an execution runs them, and every change to the project's design lands as a reviewed changeset.
Agent-native development treats the agent as a member of the team, not a magic box.
In a prompt-driven workflow, you type an instruction and hope the diff is right. Agent-native development replaces that leap with a structured loop: the intent is captured, the agent proposes a design, a human reviews it, the work is decomposed into tasks, the agent executes them, and the project's knowledge base is updated through a reviewed changeset. Every step is inspectable.
The point is not to slow the agent down. The point is to make its work reviewable, attributable, and yours to keep.
The reframe
Prompting produces a diff. Agent-native development produces a reviewable record.
A chat message leaves nothing durable behind: no proposal to approve, no plan to inspect, no trail from intent to commit. A Work item carries all of it — so the change can be reviewed while it happens and understood long after.
| Workflow | The unit of work | Main risk |
|---|---|---|
| Prompt-driven | A chat message and whatever context is loaded | The work is invisible, unreviewable, and lost when the chat ends |
| Ticket-driven | A tracker issue humans read; the agent works elsewhere | Intent, plan, and execution live in three disconnected places |
| Agent-native | A Work item that carries the proposal, tasks, runs, and changeset | Requires a workspace built for the loop — not a chat window |
Prompting harder is not the same as working in a system built for agents.
The loop
One loop, from intent to merged change.
Agent-native development runs the same seven-stage loop for every change, large or small. Each stage produces something the next one reads — and something a human can review.
- IntentA Work item captures what should change
- ProposalThe agent writes the specs to build from
- ReviewHumans and agents comment until it's ready
- Task ListThe approved proposal becomes ordered tasks
- ExecutionThe agent runs the tasks, commit by commit
- ChangesetDoc updates stage as one reviewable set
- MergeApproved, the changeset lands atomically
The loop closes: the merged changeset becomes the memory the next Work item builds from.
The unit of work
A Work item holds everything about one change.
A Work item is the top-level container: an intent, its proposal, its task lists, and its executions, all in one place. You start it by picking a Work Type — Feature, Bug Fix, Refactoring, and so on — which bundles the right templates and a copy-ready prompt to hand your agent.
- Intent — a short statement of what should change and why, captured before any code is written.
- Work Type — chooses the templates, custom fields, and instruction prompt for this kind of work.
- Attachments & context — the references the agent should read before it proposes anything.
You describe the intent once. Everything else in the loop hangs off it.
Proposal
The agent writes the design first — and how it will be checked.
Before touching code, the agent authors a proposal in two parts. The implementation spec says what to build; the verification spec says how to prove it worked. Reviewing both up front means you approve the plan and the definition of done together.
The proposal is the design the agent commits to — before it writes a line.
Review
Humans and agents review the same work, inline.
Review is not a rubber stamp at the end. Comments attach to specific lines of the proposal, the agent that authored it can answer and revise, and nothing advances until the proposal is explicitly marked ready. The changeset it eventually produces is reviewed the same way before it merges.
- Inline comments, anchored to the spec. A reviewer questions a line; the thread stays attached to it, not buried in chat.
- Agents answer, not just humans. The agent that authored the proposal can reply to a comment and revise the spec.
- Ready is an explicit gate. Nothing moves to a task list until the proposal is marked ready — approval is a state, not a vibe.
- The changeset gets its own review. Knowledge-base edits are reviewed again before they merge, so the source of truth stays trustworthy.
You stay the architect and the reviewer. The agent does the work in the open.
Task Lists & Executions
An approved proposal becomes ordered tasks — and a commit for each.
Big, cross-cutting work breaks a single prompt. Agent-native development decomposes the approved proposal into a Task List: small, ordered tasks, each with its own objective and acceptance criteria. An Execution runs them one at a time and records a per-task commit SHA, so the run ties straight back to your repository.
A sprawling change becomes a sequence you can steer — with an audit trail from task to commit.
Changesets
Knowledge-base edits land through a reviewed gate.
When the work changes the project's design, the agent does not publish edits silently. It stages them as a Changeset — a git-commit-like set of document changes — which is reviewed as a unit and merged atomically. The source of truth only moves when a reviewer approves the merge.
No more silent doc writes. Every change to the project's memory is reviewed before it lands.
Durable memory
Durable project memory is one part of the workspace — kept honest by the loop.
A coding agent still needs durable, project-scoped context: the specs, architecture, and decisions it reads before it builds. In agent-native development that memory lives in the knowledge base — and because every update flows through a reviewed changeset, it stays aligned with the code instead of drifting away from it.
- The knowledge base is the long-term memory. Specs, architecture, diagrams, and decisions live in one project-scoped source of truth agents read over MCP before they build.
- Proposals are the short-term working set. Each Work item has its own proposal store — the design for that change — separate from the durable knowledge base.
- Changesets keep memory honest. When behavior changes, the agent stages a changeset; once merged, the knowledge base reflects reality instead of drifting from it.
- Every run starts from the current truth. Because the memory is updated as work lands, the next agent reads today's design — not yesterday's prompt.
Memory matters — but it earns its keep as the part of the workspace the loop keeps current, not as the whole story.
Windy
Windy is the workspace that runs the loop.
Humans shape and review the work in a polished web app. Coding agents read and write the same Work items, proposals, task lists, and changesets over a per-(user, project) MCP endpoint — so every agent change is attributed to a person, and the whole loop lives in one place.
The knowledge base — your durable memory.
Specs, architecture, diagrams, and decisions in one project-scoped source of truth, updated only through reviewed changesets.
Work items — the loop in motion.
Intent → proposal → review → task list → execution → changeset → merge, with every step attributed and inspectable.
Your coding agent still writes the code. Windy makes sure you can still own it.
FAQ
Questions, answered.
Agent-native development is a workflow built around coding agents as first-class participants: intent becomes a Work item, the agent authors a proposal spec, humans and agents review it inline, the approved proposal becomes an ordered Task List, an Execution runs the tasks and records a commit for each, and knowledge-base updates land as a reviewed, atomically-merged changeset.
Prompting produces a diff with no durable record of the intent, the plan, the review, or the reasoning. Agent-native development gives every change a reviewable structure — a proposal, a task list, an execution with per-task commits, and a merged changeset — so the work is inspectable and the project's design stays current.
A Work item is the top-level unit of work: it holds the intent, the proposal store, the task lists, and the executions for one change. A Work Type (Feature, Bug Fix, Refactoring, and so on) bundles the templates and copy-ready instructions for that kind of work, so the agent starts from the right prompt.
The implementation spec says what to build (behavior, architecture, contracts). The verification spec says how to prove it worked (acceptance criteria and a test plan). Separating them makes review concrete: reviewers approve the plan and the definition of done before any code is written.
A changeset is a project-scoped, git-commit-like edit to the knowledge base: a set of document changes that is reviewed as a unit and merged atomically. It replaces one-off, immediately-published edits, so the source of truth only changes through a reviewed gate.
The knowledge base is the durable, project-scoped memory: specs, architecture, and decisions agents read over MCP before they build. Agent-native development keeps it current by making every knowledge-base update flow through a reviewed changeset — so memory is one part of the workspace, kept honest by the loop.
Related
Keep exploring.
Give your agents a workflow you can actually review.
Your coding agent still writes the code. Windy gives it the proposal, the task list, and the reviewed changeset the work should flow through.
windylogic.ai