Flue is a TypeScript framework for building agents, released this week. That sentence is unremarkable on its own — another runtime in the post-2025 agent-runtime gold rush. What is remarkable, for anyone running a robotics lab or a digital-fabrication office, is what its appearance signals: the orchestration layer between an LLM, a sandbox, and your real-world tools is no longer Python by default. The stack is forking.

Look at the snippet on Flue’s own landing page — createAgent, model: 'anthropic/claude-sonnet-4-6', sandbox: local(), tools: [...githubTools]. The architecture is familiar: model plus tools plus skills plus sandbox plus session. What is new is that the harness ships as TypeScript, with sandbox execution, OpenTelemetry traces, and MCP-spoken tools. Mastra, as Developers Digest documents, pushes the same shape from a different angle — durable agents, evals, memory, MCP — and ships it as a backend layer rather than a CLI tool. Together they are not competing with Python research code; they are competing with Python for the deploy layer.

For a robotics group at ETH, HSLU, or TU-Wien, the distinction matters. The MoveIt / ROS2 / PyTorch chain that runs on the lab bench is fine. The chain that runs in production — orchestrating a fabrication cell, ingesting BIM payloads from a Speckle stream, calling a Sonnet agent to decide when to abort a print — has been quietly migrating to TypeScript Node runtimes for a year. Flue is the moment that migration becomes visible.

←TODAY: Flue and Mastra ship TypeScript agent runtimes with sandboxes, sessions, and MCP — competing for the production orchestration layer above ROS and Python research code.
→3012: Looking back from the late 2070s, this is the year robotics labs accepted a polyglot stack — Python for research, TypeScript for orchestration, Rust for the safety-critical edge. The Pythonic monoculture broke clean.
Fulcrum: Pick your orchestrator before your model. The orchestrator decides which models, which tools, and which sandboxes you can swap; most teams pick the model first and discover later that their orchestrator constrains everything else.

Three concrete actions for the dependency graph this week. First, write down your current orchestration layer — not the architecture diagram, the actual dependency graph. For most BIM-adjacent groups it is a tangle of n8n plus Python scripts plus one homegrown Flask service. Second, identify the single points of failure: the API key in one engineer’s head, the npm package nobody pinned, the model name hardcoded in three places. Third, decide whether your next orchestration commit lands on the new TS layer or whether you are committed to the Python one for another two years. Both are valid; surprise commits are not.

The Digital Twin concept panel in PAZ’s archive is the right frame here: a twin that only shows you a dashboard is a museum, a twin that tells you what to do next is engineering. The agent runtime is the thing that turns a dashboard into a decision. Pick it deliberately.

Atelier: For PAZ’s Grasshopper↔Archicad library work, this is genuinely useful. A TypeScript agent runtime that speaks MCP fits cleanly above Speckle and the Archicad Python API — the missing piece between “we have a model” and “we have a tool that runs autonomously on a Bauleitung’s desk.” The PAZ rule applies: draw the dependency graph before you write the agent.

Hack: This Hack teaches you to surface every single-point-of-failure in your agent’s tool list before you ship. Domain: Workflow — one npm ls run from the root of any Flue or Mastra repo:

npm ls --all --prod 2>/dev/null | grep -E "@anthropic|@openai|@modelcontextprotocol" -B1

Read the output as a vendor map. Every line is a runtime dependency your agent reaches through, and the -B1 flag shows which parent package pulled it in. If you see the same vendor surface through three different paths, you have a single point of failure you did not draw in your architecture diagram — and the exercise of finding the third one is the whole point.

Sources & Further Reading

• Primary: Flue — TypeScript framework for building agents
• Reinforcing: Mastra for Durable TypeScript Agents — Developers Digest