Context and Communication
Alice’s communication design separates observation, interpretation, and expression. An illustrative example:- Observation: a software check failed after a dependency changed.
- Synthesis: the failure may relate to the dependency, but the cause still needs investigation.
- Expression: “The check started failing after the dependency change. I’m tracing that change to identify the cause.”
The Runtime Loop
An assignment begins with an objective, permitted tools and resources, expected outputs, and operating limits. Within that context, the runtime design follows an evaluation and action loop.1. Evaluation: assess the context
Evaluators examine messages, events, and relevant system state to decide whether an action is needed. The integration design includes triggers from WebSocket events, social mentions, scheduled intervals, and economic signals. Context may include documents, market information, leaderboards, or stream state, depending on the assignment and connected tools. The evaluator’s role is to establish relevance. An incoming event does not necessarily require a response.2. Action selection: choose the next step
Plugins expose the actions available to the runtime. The selection step considers the objective, evaluator output, urgency, and the authority granted to the agent. Action names in the design includepost-tweet, trigger-ad, play-game, and query-leaderboard. They illustrate different kinds of operation; an action must be provided and permitted by the relevant integration before it can be used.
Model routing is another part of the surrounding runtime. It allows the operation to select a model for the work while accounting for its usage and budget.
3. Plugin execution: carry out the action
The selected plugin connects the agent to a tool or service. It may retrieve information, prepare an output, or perform an authorised action. The result needs to distinguish what was requested from what actually happened. A failed action, an incomplete response, and a completed operation lead to different next steps.4. Memory: retain useful context
The design uses PGlite local vector storage to retain context and retrieve relevant information later. Useful records include the action taken, its result, decisions made, open issues, and information that can help with a future evaluation. Context may need to continue across social, stream, browser, and application interactions. Local-first memory describes where this context is stored. Individual models, tools, and connected services have their own execution and connectivity requirements.Continuity, Budgets, and Recovery
Persistent execution requires a way to understand where an assignment stands after an interruption. The runtime is being developed around schedules, activity records, retained context, and recoverable workflows. Those records should make completed work, unresolved work, and the next step understandable. Budgets and usage metering belong to the same operating context. They connect resource use to the assignment and its limits. Where work has financial consequences, its records also need to identify incurred costs and amounts owed. SW4P provides the settlement role in RNDRNTWRK’s operating model; the agent’s tool access and payment authority remain defined by the assignment.Knowledge and Retrieval
Alice’s knowledge design uses a curated corpus covering product and protocol material, the economic model, VAP, game information, and operating architecture. The documented corpus also includes the 555x402 specification and deployment context. Retrieval-augmented generation, or RAG, brings relevant passages from that corpus into the context for a particular task. The design uses vector embeddings and PGlite to support retrieval. Retrieval and model training are separate processes. The architecture also describes a supervised fine-tuning, or SFT, build process that prepares selected corpus material as reviewed training examples. Recording an interaction or game result can support later retrieval and strategy decisions. It does not, by itself, retrain the model.Plugin Architecture
Plugins organise three responsibilities:- Actions: operations the agent can request.
- Providers: information the agent can use.
- Evaluators: checks that help interpret context and decide what to do.
Integration roles
The following roles describe the plugin design. They are not an inventory of currently enabled connections.Game Interaction
The game-interaction design includes browser-based play:- A browser instance, including a headless instance where suitable.
- Game-state observation through the DOM or screenshots.
- Simulated keyboard input through the game’s normal controls.
- Score and outcome records that can inform later strategy.