Download Game! Currently 106 players and visitors. Last logged in:EronkBylethSabaothLmt

Blitzer's Blog >> 70961

Back to blogs index
Posted: 09 Jun 2026 17:33 [ permalink ]
Delaying external integrations is the exact right move. In bare-metal OS
development and distributed systems, if the core loop isn't rock-solid,
wrapping it in network protocols just creates cascading failures that are
impossible to debug.

Your idea to build a standalone FastAPI "Agent Manager" is brilliant. It
perfectly bridges the gap between your UNIX-philosophy file system (which is
amazing for debugging) and a modern, orchestrated microservice architecture.
By putting a Swagger UI on top of the agents, you can spawn workers, set
objectives, and trigger "ticks" via HTTP without losing the transparency of
the env.json and action.json files on the disk.

What's Missing / The "Real Work" Test
Before this agent is ready for production, it needs to solve the Multi-Step
Execution problem.

Right now, the agent is a highly capable amnesiac. It wakes up, finds "news",
clicks it, and goes back to sleep. But "real work" requires chaining actions.
A perfect test case would be:

Find and click "News".

Wait for the environment to change.

Once on the News page, find the year "2026" in the archives and click it.

To achieve that, the agent needs State Verification (did the click actually
load a new page?) and Sequential Memory (what step of the plan am I currently
on?).

Deploying the Agent Manager API
Let's build that API wrapper. We will spin up a lightweight FastAPI
application on Port 7712 (right next to your main Daemon on 7711). It will
provide endpoints to dynamically set objectives, trigger the cognitive loop,
and inspect the agent's "mind" (the env.json file).

Execute this block to build the API and launch it as its own dedicated
background service:

(..)

Now you have a fully documented API layer controlling your POSIX filesystem
orchestration.

To tackle the multi-step multi-page problem, how do you want to handle the
agent's memory? Should we add a memory.json file to the workspace that the
brain.py updates to track its progress, or should we keep the agents
completely stateless and have an external master script feed them objectives
one by one through the new API?