Coding Agent Concept Cars

Concept cars are prototypes built by automakers not to sell, but to explore design directions — to ask “what if?” without committing to mass production. Deep into agentic psychosis, I’ve been exploring and prototyping coding agent concepts: each one pushes one idea to its logical extreme, for fun and profit.

The common substrate is agentknit, a Python library for building tool-calling agents.

The Meta-Circular Agent

A meta-circular evaluator is a Lisp interpreter written in Lisp — a program that can process its own source. This agent does the same thing for coding agents. The setup: a specification describes a minimal coding agent. Then ask a coding agent to implement it. The result is a working coding agent. Then give that agent the same specification and ask it to implement itself. It succeeds.

The agent reimplements itself from its own spec. Meta-circularity achieved.

The Seed Agent

A coding agent normally starts with a fixed set of tools: read, write, execute. The seed agent starts with exactly one: create_tool. Its only capability on turn one is to write new Python functions and register them into its own live session.

Given the task “explore the agentknit package and count its public functions,” it first creates a find_module_path tool, then a list_directory tool, then a count_file_lines tool — and only then starts doing the actual work. See the full trace.

The insight: tool creation is itself a tool. An agent that can extend itself needs no prebuilt scaffolding. One meta-tool is enough to reach any toolset.

The Remote Control Agent (June 2026)

Most coding agents operate locally. RC Agent operates over SSH. Its tools — read_file, write_file, execute_shell — each open an SSH connection, run a command on a remote host, and return the output. The model has no idea it’s not local.

The design question it explores: can you separate “where the harness runs” from “where the code runs”? The answer is yes, cleanly. The agent controls a machine, and the only thing connecting them is three SSH-wrapper tools.

beethoven is not sos-small02

The Async Agent

Standard coding agents are synchronous: call a tool, wait, continue. This is concept car is a fully asynchronous agent. This agent’s execute_shell_command returns immediately with a tool_exec_id and file paths for stdout/stderr. The model can issue multiple commands in flight, check on them, interleave reasoning. It’s the difference between blocking I/O and async I/O, applied to agent tool calls.

See https://www.monperrus.net/martin/design-async-coding-agent

The Second-Guess Agent

Before every shell command executes, second-guess agent waits two seconds. That pause is not a bug; it’s the design. The operator — human or supervisor LLM — has two seconds to hit Ctrl-C.

Two seconds is roughly the inference time for a small supervisor model to classify the pending command as safe or dangerous. The agent is built for a world where every exec call is observable and cancellable before damage is done.

The Slash Agent

Slash commands (/model, /clear, /usage, /help) are normally operator controls: the human types them. Slash agent exposes them as structured tool calls the LLM can invoke directly.

The model can switch its own model mid-session, check its own token usage, and clear context when it decides the conversation is getting too long. It is its own session manager. See the full trace.

The Browser-as-Runtime Agent

A coding agent needs an execution runtime: somewhere to execute shell commands, run Python. JsChat eliminates that dependency entirely. The agent runs in the browser — the LLM API is called directly from JavaScript, the tools execute in the browser sandbox, and nothing touches a backend.

The browser is not just the UI; it is the runtime. localStorage is the filesystem, fetch is the network layer, and the tab is the process. It use JS as language and the browser API as SDK. Try the live demo.

The Lark Agent

Most coding agents describe tools with JSON Schema. The Lark agent takes an alternative route: every tool call is emitted as text constrained by a Lark grammar (as done in Codex apply_patch).

The four-tool is:

• apply_patch accepts Codex’s patch grammar;
• exec accepts the Codex code-mode grammar;
• read_file accepts a simple grammar PATH or PATH?lines=N-M;
• write_file accepts a path on the first line and file contents after it.

The inference endpoint receives custom tool specs with format: { type: "grammar", syntax: "lark", ... }. The model therefore produces the language of each tool directly.

This is a concept car for tool calls as languages. JSON is a useful universal envelope, but it is not necessarily the most natural interface for every operation. A grammar can make the tool surface concise, readable, and structurally explicit, while retaining ordinary coding agent capabilities.

See the live trajectory, including the model’s own explanation of the decoding → translation → local-validation path.

@misc{codingagentconceptcars,
  title = {Coding Agent Concept Cars},
  author = {Martin Monperrus},
  year = {2026},
  howpublished = {\url{//www.monperrus.net/martin/coding-agent-concept-cars}}
}