Drawgent Puts a Coding Agent on a Live Whiteboard

Drawgent is an open-source bridge between a live Excalidraw canvas and coding agents that users already have installed. It does not bundle a model or create a separate agent account. Instead, it connects Claude Code, Codex, or opencode to a workspace, lets the agent inspect a screenshot and structured scene data, and gives it tools to add, update, or remove canvas elements.

The project reached 133 Hacker News points and 35 comments when checked on September 27. That is a meaningful early developer-attention signal, not evidence that the tool improves design accuracy or team throughput.

What happened

Drawgent’s basic interaction is spatial. A user can ask for a diagram through a chat panel, write an AGENT: note beside a shape, connect that note with an arrow, or circle an area with Excalidraw’s laser tool. The agent receives the instruction together with position and nearby-element context. When it finishes, the note becomes a green DONE marker and the resulting edits remain visible on the canvas.

The tool can also join an encrypted Excalidraw collaboration room as an agent participant. Humans remain in the familiar web canvas while the local bridge connects their requests to an agent session. Prompts are queued one at a time, which avoids two instructions changing the same scene simultaneously.

Session behavior differs by agent. opencode and Codex can receive messages in a running session through their available integration paths. Claude Code is forked into a new ACP-driven session because the project says there is no public way to inject messages into the existing terminal session. Drawgent’s setup checks the agent CLI, login state, ACP bridge, canvas tools, and a Chrome or Chromium renderer before it starts.

Why it matters

Most agent interfaces describe work as a sequence of messages. That is awkward for diagrams because “move the box near the database” or “redraw only this boundary” depends on visual context. Drawgent turns position into part of the instruction. The user can point at a region rather than translating it into a long textual description.

The more important design choice is that the visual artifact remains inspectable. An agent can show the proposed architecture, a reviewer can mark one uncertain edge, and the next change is visible rather than buried in a transcript. This creates a small review loop: indicate, edit, inspect, and refine.

It also demonstrates a useful integration pattern. The agent remains the user’s configured CLI with its existing repository, authentication, and policy. The canvas becomes another tool surface. That reduces the risk of a diagram product silently introducing a second model, a second memory, or a second set of credentials.

Evidence

The official repository documents scene and screenshot tools, Mermaid import, bound arrows, element updates, instruction resolution, room synchronization, and an HTTP and WebSocket API. The implementation is primarily Rust, with a browser editor and renderer. Tests cover room cryptography, chat turns, canvas notes, browser input, room synchronization, and laser-zone editing.

The README is also candid about limits. Chrome is currently required for rendering. A workspace gets one scene. Images and files do not synchronize. Claude attachment creates a fork. Most importantly for EgoistAI readers, the Codex live-attachment path was implemented but had not yet been tested against a logged-in Codex when the repository was checked.

The default permission policy automatically approves drawing tools while asking for approval for other actions. That is a sensible boundary, but it does not prove that every connected agent or shared room is safe. The repository remains the source for current behavior; early community comments should be treated as feedback, not validation.

Practical takeaway

Teams evaluating Drawgent should begin with a non-sensitive repository and a disposable diagram. Confirm which session is actually connected, which tools are automatically approved, where .drawgent/scene.json is stored, and whether joining a room introduces any data-handling concerns. Test Stop, reconnect, and failed-render behavior before using the canvas during a consequential design review.

The best use cases are bounded visual tasks: architecture maps, data flows, sequence diagrams, review annotations, and planning a change around existing components. The weakest use case is asking the same agent that wrote a system to produce an authoritative diagram and then accepting the picture without checking the source. A visually persuasive explanation can still omit a security boundary or invent a dependency.

For shared sessions, retain the diagram in version control or export it with the decision record. The picture becomes valuable when it links to evidence and survives after the agent session, not merely when it looks polished.

Limitations

Drawgent is early software with one primary maintainer source and limited independent evaluation. We did not install it, test its room encryption, measure latency, or verify attachment behavior across all three agent CLIs. The community signal is modest and may reflect novelty.

The project also depends on several moving interfaces: agent CLIs, ACP adapters, Codex session files, Chrome rendering, and Excalidraw room behavior. A change in any layer can break attachment or produce a partial scene. Teams should expect integration maintenance.

Finally, spatial prompting does not solve semantic verification. A reviewer still needs to know whether the drawn service, permission, sequence, or data path matches the actual system.

Final verdict

Drawgent is interesting because it treats a whiteboard as an action surface for an existing coding agent, not as a static export. Its spatial notes, laser zones, visible completion markers, and conservative drawing permissions create a more legible human-agent loop. The concept deserves testing, while the untested Codex path and young integration stack make it a prototype to evaluate rather than infrastructure to trust by default.