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 One Tool Agent — the coding agent with exactly one tool.
Most agent harnesses ship five to ten tools: read, write, edit, glob, grep, run. onetool_agent.py strips that down to a single exec_shell, and tells the model so in the system prompt — there is no read_file, no write_file, no edit_file; every inspection and every edit has to go through cat, echo, sed, tee, and friends. The interesting part i is watching the model fall back on exactly the unix literacy a human operator would use: cat to read a file, sed -i ‘s/old/new/’ for a targeted edit, a cat > file <<EOF heredoc for anything multi-line. It’s a reminder that “coding agent tools” are mostly a paved-road convenience layer over capabilities the shell already has and that a capable model doesn’t need them to get the job done. See https://github.com/ASSERT-KTH/cacc/blob/main/onetool_agent.py.
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.
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 Mixer Agent
A coding agent is normally controlled through a chat window. The Mixer Agent turns a $60 MIDI mixer into a physical cockpit for eight parallel coding agents: one agent per channel strip.
The mixer’s spawn, mute, solo, record, and fader controls become agent controls. An operator can launch or stop a particular agent, steer voice focus to it, and set its reasoning effort without hunting through windows. The question is whether controlling a group of agents is less like chatting and more like conducting an orchestra. With a spatial, hands-on interface, the answer looks promising.
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_patchaccepts Codex’s patch grammar;execaccepts the Codex code-mode grammar;read_fileaccepts a simple grammarPATHorPATH?lines=N-M;write_fileaccepts 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.
The Wasm Agent
Most coding agents execute code through a shell, and sandboxes a
shell only partially. wasm_agent
removes the shell entirely: its only execution tools are
compile_rust_to_wasm (rustc, wasm32-wasip1) and
wasmtime_exec. To observe anything about its own code, the
agent must write Rust, compile it to WebAssembly, and run it under wasmtime — inside a capability sandbox
with no ambient filesystem, no network, no process spawning, and a
deterministic fuel budget that traps infinite loops instead of timing
them out. See the
full post.
The Remembering Agent
What if an agent remembered every session it had ever run in a
repository, and remembering cost nothing until it looked? Coding agents
already write down everything they do — each one keeps a full trajectory
of my instructions, its tool calls and their outputs — and then never
reads it back. The concept car mounts that history as a filesystem:
expose past sessions at ./memory, one JSON file per past
session. The agent needs no new special capability to use it: it greps a
directory and reads the interesting file, which is the behaviour it is
best at. See Exposing
Past Sessions as Memory for Coding Agents for the full design.
The Epistemic Agent
A transcript tells you what an agent ran, never what it thought it was doing. This concept car makes the justification part of the call: every bash invocation carries a mandatory type — one of collect-info, test-hypothesis, change-state, verify, setup, revert, cleanup — and a mandatory free-text reason. Untyped or hand-wavy calls are rejected in-process and never reach the shell. The interesting part is that the type depends on the agent’s epistemic situation rather than on the command: pytest -q is test-hypothesis when a particular failure is expected, and verify when finished work is being confirmed. The trace and its rationale are the same artifact — interpretability at the boundary where the model stops thinking and touches the world.
See https://www.monperrus.net/martin/epistemic-agent
The Open Science Agent
Most coding agents leave behind, at best, an opaque provider log. The Open Science nt treats an agent trajectory as a research artifact: each semantic operation — a user instruction, tool call and outcome, or assistant response — is written immediately as readable JSON and committed to a session-local Git repository. The design question: can an agent’s memory also be its audit trail? Yes. The same history that lets an agent resume work across sessions is independently inspectable, reviewable, comparable, and potentially citable by others.