Skip to content

Instantly share code, notes, and snippets.

@bparanj
Last active May 22, 2026 12:00
Show Gist options
  • Select an option

  • Save bparanj/73fa555c8430d70c5d28cbc8d4d1e450 to your computer and use it in GitHub Desktop.

Select an option

Save bparanj/73fa555c8430d70c5d28cbc8d4d1e450 to your computer and use it in GitHub Desktop.
Agents via Code Execution Not Shared State

The article

channels/devto/agents-via-code-execution-not-shared-state.md — "Thoughtworks Just Moved LangGraph Out of Adopt. Our Security Tool Was Already Built for What Comes Next."

It makes the positioning argument you spotted: the 4-agent workflow proves Stave already embodies the pattern the Radar now favors — simple agents communicating through code execution, each scoped to the state it needs — without being an agent framework.

The spine of the argument:

  1. The Radar's two real claims — communicate through code execution (not a shared blackboard); each agent gets only the state it needs (not a global object).
  2. The workflow that gave it away — the observe→evaluate→prove→attest pipeline, highlighting what's absent: no AgentState, no up-front graph, no agent that can corrupt another's memory. Agent 3 doesn't know Agent 1 exists; it consumes a snapshot, not Agent 1's variables. The integration surface is files + exit codes.
  3. Scoped state falls out for free — because the unit of work is a single-responsibility command over an explicit input, "the argument list is the scope." (Table contrasting global-shared-state vs command-and-file composition.)
  4. The hidden requirement: determinism — ties straight back to the prior article. Code-execution composition only works if a command's output is trustworthy as a message → same input, same bytes. That's what lets agents cache, verify by re-deriving, and lets humans debug any command in isolation. Provenance via deterministic fact_id vs the no-provenance blackboard.
  5. We made it stronger by deleting things — the scope-narrowing (removing monitoring/planning/forensics/enrichment/orchestration) is reframed as "we resisted growing our own graph; we kept leaf functions and let the agent be the graph, when one is even needed" — mirroring the Radar's "add graph structure later."
  6. Takeaway — if you're building a capability for agents (not the framework): expose deterministic commands over explicit files, scope each to its inputs, let the caller own the graph. Closing line: "We didn't build for agents. We built for determinism and single responsibility. It turns out that's the same thing."

It pairs naturally with the determinism article — that one explains why the commands are deterministic; this one shows why that's exactly what makes them agent-composable. Both are published: false drafts, grounded in real commands/files (apply, gaps, export-sir, export compliance, the Steampipe contracts, the reasoning spec), and free of internal hashes/dates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment