CodingAgent in Kavor: your favorite harness as part of a graph
A CodingAgent is your coding agent running through its provider's native interface, now as a visible participant on the Canvas.
Kavor does not replace each harness with a generic chat. It preserves the provider experience and adds structure around it: an explicit responsibility, reachable context, tools, other CodingAgents, and boundaries you can inspect.
See how to select a CodingAgent provider → (opens in a new tab)
What a CodingAgent owns
Each CodingAgent represents a separate session. The Node preserves the configuration and state needed for that role, including the selected provider and, when the provider exposes them, model, effort level, permissions, and native session.
The provider is a CodingAgent setting, not a different Node kind. The selector includes:
- Anthropic Claude Code;
- OpenAI Codex;
- Google Antigravity;
- xAI Grok;
- SST OpenCode.
When you add a CodingAgent from the toolbar, you choose the provider first. You then configure that session for the work. Available options can differ because Kavor preserves the real capabilities of each harness instead of pretending they all share one contract.
What it can do on its own
Without any Connection, a CodingAgent is still a provider-native session inside the Workspace. You can talk to it, use the tools the harness provides, and choose its working directory. That directory may be outside the Workspace root when the role needs another repository or worktree; its association remains explicit in the session.
The Node already helps separate contexts: one session can investigate while another implements. Without a graph, however, shared context still depends on what you put into each conversation.
A Connection turns the isolated session into a participant in a system of work.
Provide a file or screenshot in the input
In an open session, you can paste operating-system clipboard files or PNG/JPEG images. Kavor inserts a file reference without creating a File or Connection on the Canvas. Check the path and write your request before submitting it; interpreting the image still depends on the harness.
The Terminal guide explains the procedure, limits, and difference between a pasted reference and a resource kept in the graph.
What it gains from the graph
A CodingAgent can work with any Node reachable through valid Connections in its component. Not every resource needs to connect to it directly.
Direct Connections involving a CodingAgent have specific roles:
| Connection | What it adds |
|---|---|
| CodingAgent+Specification | Places durable intent, scope, and criteria in the graph. The direct Connection may carry specification_read_only. |
| CodingAgent+Sticky Note | Adds shared informal memory for open decisions, progress, and findings. It may carry sticky_note_read_only. |
| CodingAgent+File | Makes a canonical filesystem source explicit in the work. It may carry file_read_only. |
| CodingAgent+Terminal | Allows commands, process observation, and shell evidence. It may carry terminal_read_only. |
| CodingAgent+WebBrowser | Allows the agent to observe and operate that WebBrowser's real pages in the same state visible to the human. |
| CodingAgent+CodingAgent | Joins participants in one component. Reachable CodingAgents can exchange asynchronous messages and inspect the context needed to coordinate. |
| Trigger+CodingAgent | Selects that active session as the direct target of a scheduled prompt. A Trigger does not start a session you closed. |
Reachability does not erase direct contracts. If the exact Connection between a CodingAgent and a resource has a Guardrail, that restriction still governs the pair even when another route exists through the graph.
Useful patterns
Implement from a contract
Connect a Specification, a CodingAgent in the Implementer role, and a Terminal. The agent reads the contract at its source, changes only the necessary scope, runs the checks, and records outputs on the Specification.
This keeps intent outside the conversation history and evidence inside the Workspace.
Separate implementation from review
Use different sessions for the Implementer and Reviewer. Both can reach the same Specification and evidence, but each receives a different question.
The Implementer asks, “how do I satisfy the contract?” The Reviewer asks, “does the result actually satisfy the contract, and what risks remain?” Separation reduces the chance that review automatically inherits the author's assumptions.
Combine providers without creating a contest
Different providers can participate in the same graph. Combine them when another interface, model, or reasoning approach improves a concrete responsibility.
Do not add a provider just to increase the number of agents. Define the role, expected result, and stopping condition first; then choose the harness that best serves the work.
Work with a live page
Connect a WebBrowser when the task depends on a real web interface. You keep seeing and using the same tabs while the CodingAgent can navigate, interact, wait for changes, and capture evidence without reconstructing the page from text pasted into chat.
The WebBrowser can stay alive when you switch Workspaces and return in the same state. This lets the agent continue already authorized work without reloading the page at every visual context switch.
See a CodingAgent working with WebBrowser → (opens in a new tab)
Inspect another CodingAgent's current session
A reachable CodingAgent can passively page through completed turns from another CodingAgent's current provider-native session. This recovers reasoning, evidence, and context that has not yet become a message or durable output.
The read does not send provider input, activate the inspected session, or replace a message when the other agent needs to act, decide, or answer. If that session changes during pagination, the old continuation is rejected; the reader must start again instead of mixing different histories.
A practical graph
Specification — Implementer — Reviewer
│ │
Terminal Sticky Note
│
File
The lines represent Connections with no persisted direction. Every Node belongs to the same reachable component. The Implementer executes the contract, the Reviewer produces an independent assessment, and the Sticky Note keeps questions or findings visible for the human decision.
This design is not an automatic sequence. Messages coordinate handoffs; Specifications and other resources preserve what must survive sessions; you decide when the work is accepted.
A better opening prompt
For an Implementer:
Implement only the scope defined in the reachable Specification. Before changing code, identify the relevant Files and checks. Use the Terminal to produce evidence, record the result as a Specification output, and ask the Reviewer for an independent assessment. Stop if a required decision falls outside the contract.
For a Reviewer:
Compare the implementation and evidence with the Specification criteria. Look for incorrect behavior, missing scenarios, regressions, and operational risks. Record concrete findings before suggesting changes, and do not approve the work merely because existing tests passed.
Example: a handoff the Reviewer can verify
Imagine a fix to a registration form. The Specification requires an invalid email address to show a message, submission to be blocked, and a valid email address to keep working. Use the graph above and keep Builder and Reviewer in separate sessions.
Request to the Builder:
Implement the validation defined in the Specification. Preserve the valid path's behavior. Run the relevant tests in the Terminal and record changed files, commands, and results. Then send the Reviewer the Specification handle and the exact commit or diff to review. Report outstanding items and stop before publishing.
A useful handoff identifies the deliverable instead of copying the entire conversation:
The implementation is in the commit referenced in the Specification outputs. The invalid, empty, and valid email tests passed in Terminal Checks. Review the criteria and failure paths in that commit. Record findings with the file, scenario, and evidence; reply when finished. Do not change code during this review.
Request to the Reviewer:
Read the contract and examine the referenced deliverable. Verify each criterion, reproduce the relevant scenarios, and add your conclusions to the Sticky Note. Distinguish a demonstrated defect from a hypothesis. If you find a blocker, explain which behavior fails and send it back to the Builder for correction.
The expected result is an identifiable change, an independent review, and your evidence-based decision. If the Builder is still changing the deliverable, wait for it to stabilize or explicitly define what is ready for review. Two agents looking at different code revisions are not assessing the same deliverable.
Limits that matter
- A CodingAgent does not receive access from visual proximity; a path of Connections must exist.
- Referencing a Node in a message does not grant access to it.
- Passively reading another CodingAgent's session does not activate it or transfer a durable decision into the Specification.
- A Guardrail restricts the direct pair it belongs to; it is not a global Workspace policy.
- Messages coordinate work, but must not be the only place where a durable decision lives.
- Providers do not necessarily expose the same models, permissions, events, or session operations.
- A Trigger delivers a prompt to an active session; it does not expand permissions or guarantee an external effect happens exactly once.
- Allowing Canvas edits does not authorize deleting Nodes or changing Guardrails; those boundaries remain human.
Before starting the session
Confirm:
- what responsibility this CodingAgent owns;
- what observable result it should produce;
- which Nodes must be reachable;
- which Guardrails should exist on direct Connections;
- whether the provider, model, and effort fit the task's risk;
- where decisions, progress, and evidence will be preserved;
- who it should talk to and when it should stop.
A CodingAgent does not become powerful because it received a longer prompt. It becomes more useful when responsibility, context, tools, collaboration, and boundaries form a coherent design.
Continue with How to choose CodingAgents and define roles, learn how CodingAgents see and build the Canvas, or consult the supported Connections matrix.