Architecture AI Updates: October 23, 2026
1. Actors for Agents: Treat Each Unit of Agent Work as a Supervised, Addressable Actor
InfoQ (Manju Rajashekhar). In a QCon AI talk published by InfoQ, Mad Labs founder Manju Rajashekhar (formerly on Twitter’s early caching team) argues that production agents are distributed systems (stateful, concurrent, long-running, partially failing) and that the actor model fits them better than function calls, queues, and ad hoc workers. He proposes five patterns: a single “task” actor as the universal primitive for chat turns, tool calls, sub-agents, and human-in-the-loop waits; write-through state, so every meaningful transition is persisted and crash recovery follows the normal resume path; indirect continuation, which stores what a task intends to do next instead of holding a call stack while waiting on slow tools or people; a mutable execution graph in which work spawns further work at runtime; and supervision trees that assign restart, stop, escalate, or keep-partial policies by position. All inputs, including user follow-ups and cancellations, go through one mailbox, and every unit of work gets an addressable identity. His reference coding agent, written in Rust, uses four actors (supervisor, LLM transport, tool registry, and the agent loop); the talk presents no benchmarks and notes that no mainstream agent framework uses this model yet. Source
2. AI Changes the Data Interface, Not the Query Engine
InfoQ (Peihao Yuan). Drawing on a disaster-recovery analysis, Peihao Yuan argues that agents change how analytical data is accessed and interpreted but do not remove the need for a precise computation engine. The core pattern is a “determinism split”: an embedded engine (DuckDB, reading Parquet directly from S3-compatible storage, with filter pushdown and spill-to-disk) handles filtering, joins, aggregation, windows, and data-quality checks, while the agent selects evidence, classifies, explains, and abstains when evidence is thin. Agent-proposed SQL or Python is validated against a table allowlist and read-only operations, run in a sandbox, and condensed by application code into compact “fact packets” that the model must cite, so every number in its output comes from the engine. Other recommendations include self-describing datasets (index, manifest with schema and checksums, and config files), explicit semantics for missing values, steady-state baseline windows, and a replay bundle with inputs, generated code, prompts, and model identifiers; a managed lakehouse or Apache Iceberg should be added only when multiple consumers, data gravity, large shared joins, or concurrent writers require it. Source