James Arthur from ElectricSQL - agents are data, not compute (Heavybit DevGuild)
ElectricSQL's James Arthur argues that an agent is a long-lived session record, not a computer: the compute should scale to zero while the agent's state remains queryable, branchable and available to people and other agents.
James Arthur is the co-founder and CEO of ElectricSQL. Electric began as a Postgres synchronization engine and is now applying its data and sync primitives to collaborative multi-agent systems through Durable Streams and Electric Agents.
Recorded at Heavybit DevGuild, this conversation explores why putting every agent inside its own black-box computer is inefficient, why session history belongs in the data layer, and how separating agent logic from tool execution can make online agents easier to scale, observe and move between infrastructure providers.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How has Electric evolved from Postgres sync into agent infrastructure?
Many people know Electric as a synchronization engine for Postgres. We generalized that technology into data primitives for agents, including Durable Streams for storing session data and coordinating multi-agent systems. Electric Agents is the runtime on top: an open-source execution layer where agents behave like serverless logical entities and can scale down when they are inactive.
Why do you say agents are data, not compute?
An agent is better understood as its session record. It might represent a CI process, a pull request, a customer interaction or an object in a room, and it should continue to exist when it is not running. If the agent disappears when its virtual machine stops, the model is wrong. Persist the state in the data layer, then attach compute only when work needs to happen.
What changes when agents move online?
The important transition is from one local agent to connected systems of people and many agents. Companies need communication, coordination and data connectivity as work moves from being performed only by people to a hybrid of people and agents. That is a distributed-data problem, which is why Electric approaches it through synchronization rather than beginning with a sandbox.
What is wrong with giving every agent its own computer?
Local coding agents were designed around the observation that models are good at using a computer, so they received a file system, shell and tools such as grep. Moving that environment into a container or VM preserves an awkward architecture. Session logs and sub-agent decisions end up buried inside hidden files or black-box sandboxes instead of systems a company can query, inspect and govern.
Why does the computer-per-agent model become inefficient at scale?
A company may eventually have an agent for every step in a process and every customer touchpoint. Giving each logical agent a virtual machine with gigabytes of memory wastes enormous resources. The session should persist while compute hibernates or scales to zero, allowing the same conversation to resume or branch later without keeping an entire machine alive.
How can agents execute tools without living inside a sandbox?
Separate agent logic from tool-call execution. An agent generating a report should ask a controlled database system to run SQL rather than hallucinating a CSV. File operations and other tools can likewise run through appropriate online services. A lightweight function can execute the agent's reasoning, while deterministic platforms perform the actions and expose the instrumentation needed to monitor them.
How does Electric avoid locking the agent to one cloud?
Cloud platforms offer excellent agent infrastructure, but naturally encourage customers to run compute inside that platform. Electric works from the data layer and keeps the technology open source, so a product team can own its infrastructure and choose where the computation runs. The durable session and coordination primitives do not need to be tied to one hosting provider.
What does it take to try Electric Agents?
The ideas sound complex, but the quick start runs through NPX. Developers define agent entities much like functions or request handlers and can continue using the AI framework they already prefer. Existing agent definitions can be wrapped for the runtime so they gain the data primitives needed for coordination and connection without rewriting the application around a proprietary framework.