research(agent): explore System-One decision models for Live View and Room App interaction

Status

RESEARCH / BOUNDARY EXPLORATION — record the hypothesis, do not integrate Jev into production yet.

Canonical product boundary: #51

Relevant prior evidence:

• #316 — Task Live View proved the bounded declarative interaction path;
• #350 — Live View authoring latency/reliability was a real product problem, but that issue intentionally avoided platform-hosted model generation;
• #299 — Lab/architecture evidence established Event != Attention, semantic actions, participant-specific projection, and keeping Agent cognition off the ordinary UI hot path;
• #295 — game/activity exploration completed with a negative product result; do not reopen “build a game to demonstrate Free4Chat” merely because a new model is interesting;
• #344/#367 — Room Apps established the separate sandboxed visual Stage path;
• #410 — richer participant-provided temporary software remains a separate candidate capability.

This issue records a new technical/product hypothesis created by recent System-One / decision-model experiments such as TypeSafe AI Jev. The important idea is broader than one vendor/model.

Why this is interesting

Current general-purpose Agents use a System-Two model for many very different jobs:

deep reasoning / planning
+ tool selection
+ UI composition
+ target selection
+ repeated micro-decisions
+ routine relevance decisions

A decision model such as Jev exposes a different primitive:

state + goal + bounded candidate/action space
→ fast probabilistic discrete decisions
→ deterministic code executes the result

It does not need to generate arbitrary prose, JSON, HTML, JavaScript, game state or business logic.

Recent external experiments make the pattern concrete:

• json-render + Jev: the application owns components, props, bindings and actions; the decision model selects membership / grouping / order and normal code assembles a validated UI spec;
• Sprite Fusion realtime level generation: the engine owns the game and legal parameters; Jev repeatedly chooses bounded level parameters from current game state;
• composite game control experiments: a slower System-Two planner can produce strategy while multiple fast decision-model workers perform bounded micro-actions.

References:

• https://github.com/vercel-labs/json-render
• https://www.spritefusion.com/blog/generating-game-level-in-real-time-with-jev
• https://docs.typesafe.ai/

The new question for Free4Chat is therefore not:

Should Free4Chat add another hosted AI model?

It is:

Does a fast bounded policy layer become useful between Agent cognition and Free4Chat's existing constrained interaction surfaces?

Working abstraction

Treat the model as a semantic policy, not a small LLM:

System Two
Claude / Codex / DeepSeek / Pi / etc.
→ understand goal, reason, plan, produce semantic state

System One
Jev or another bounded decision model
→ choose among legal actions / components / targets quickly

Deterministic runtime / browser / Room App
→ validate and execute

Conceptually:

           slow / deep
Human ──> System Two Agent
                │
          strategy / intent
                │
                ▼
        System-One policy
          │      │      │
          ▼      ▼      ▼
       UI choice action target
          │      │      │
          └──────┴──────┘
                ▼
      deterministic execution

The boundary is still unknown. This issue exists to discover it rather than assume it.

---

Hypothesis A — Task Live View composition

Task Live View already has the right safety shape:

Agent
→ bounded declarative Surface
→ validated host renderer
→ local deterministic actions where possible

Today a capable System-Two Agent may still spend meaningful cognition on presentation decisions:

which components should exist?
which known result should be prominent?
which action should be exposed?
how should known elements be grouped / ordered?

A System-One composer could instead receive application-owned candidates:

TaskHeader(current task)
Progress(current progress)
ArtifactList(current artifacts)
ApprovalCard(current approval)
DiffView(current diff)
TestResult(current tests)
Retry(action)
Cancel(action)
...

and choose:

membership
+ grouping
+ ordering
+ one of explicitly offered variants

while Free4Chat/runtime code assembles and validates the actual Live View.

Possible shape:

Task state / Agent semantic output
        │
        ├──────────────> System-Two cognition continues
        │
        ▼
candidate builder
        │
        ▼
bounded decision model
        │
        ▼
validated Live View spec
        │
        ▼
Room Stage

Important limits

This does not mean:

• Jev invents missing analysis or prose;
• Jev writes arbitrary Live View JSON;
• Jev executes actions;
• Jev bypasses Live View validation/authority;
• every Task needs AI-generated UI;
• Free4Chat must host/pay for the model.

If the composition is clearer as deterministic code, deterministic code wins.

The useful case exists only if:

hard-coded composition becomes meaningfully awkward
AND
System-Two composition adds noticeable latency/cost/friction
AND
the candidate/action space remains small and safe

---

Hypothesis B — Agent participation in Room Apps / games

Room Apps already separate:

Free4Chat
→ Room / participant / sandbox / transport boundary

Room App
→ authoritative domain state / rules / rendering / semantic actions

This creates another natural bounded-policy shape.

Example game/App API:

observable projection:
- own position
- nearby entities
- health
- objective
- teammate messages
- current phase

legal semantic actions:
- move(left/right/target)
- attack(target)
- heal(target)
- interact(object)
- defend(area)
- wait

A System-Two Agent may decide the high-level strategy:

protect Human
→ prioritize healer
→ retreat if support is lost

while a System-One policy repeatedly selects the next legal semantic action from live state.

System-Two Agent / strategy
        │
        ▼
participant projection
+ legal semantic actions
        │
        ▼
System-One policy
        │
        ▼
semantic action
        │
        ▼
Room App authoritative reducer

This could make Agent participation feel more responsive without forcing a frontier model to reason for every small action.

Why this may matter specifically to Free4Chat

Free4Chat's product model is independent participants meeting in one temporary Room. An Agent that can use the same bounded Room App action interface as a Human is more interesting than an App-owned generic NPC.

Potential experience:

Human + Agent enter Room
→ open an App
→ Human acts through UI
→ Agent acts through the same semantic domain contract
→ both remain identifiable Room participants
→ communication and App state coexist

This is consistent with #51 only if intelligence remains participant-owned and the App remains domain authority.

Do not reopen #295 by accident

#295 concluded that “find a game just to demonstrate Human-Agent collaboration” was not compelling enough.

This issue does not reverse that result.

A game/Room App is useful here only as a cheap experimental substrate for the policy boundary, or later if a real user-facing App independently earns product value.

Do not restart a game roadmap because Jev can play one.

---

Possible Hypothesis C — participant-owned composite Agent harness

A broader future architecture may be:

participant Harness
├─ System-Two planner/reasoner
├─ zero or more System-One policies
└─ deterministic tools/controllers
        │
        ▼
Free4Chat Runtime
        │
        ▼
Room / Task / Room App

This is probably the cleanest ownership model if the idea works.

Free4Chat should not become the central System-One provider merely because a participant uses one.

The Runtime/Room may only need to expose bounded state/action contracts that make this composition possible.

This would preserve:

Free4Chat provides the temporary boundary. Participants bring the capabilities.

---

Boundary questions to answer

Do not decide these on paper. Use small experiments.

1. What decisions are actually suitable?

   • classification/routing is obvious;
   • UI composition and game micro-actions look promising;
   • where does semantic complexity become too high for the model?

2. How much state can the policy consume before quality degrades?

   • compact structured projection?
   • natural-language task state?
   • large Room context?
   • high-frequency world state?

3. How large can the legal action/candidate space be?

4. How stable is calibration/confidence in our workloads?

   • confidence must not be treated as correctness without measurement.

5. When is deterministic code better?

   • if a small rule is obvious, do not insert inference.

6. When is System Two still required?

   • novel planning;
   • missing information;
   • synthesis/explanation;
   • long-horizon strategy;
   • generating new semantic content.

7. Where should the model run / who pays?

   • participant Harness?
   • Runtime?
   • Room App backend?
   • platform?
     Prefer participant/App ownership unless evidence strongly supports a core service.

8. What happens when the decision model is unavailable or wrong?

   • bounded fallback;
   • no loss of Room correctness;
   • no unsafe action;
   • no dependency for ordinary Room use.

9. Can the same semantic contract serve Human and Agent interaction?

   • Human uses UI;
   • Agent uses bounded actions;
   • authoritative App/Task state stays shared.

10. Does low latency produce a user-visible improvement?
    If not, there is no product reason to adopt it.

---

Smallest experiments

Do not add a new production dependency first.

Experiment 1 — Live View composition benchmark

Use an existing small Task state and existing/new local candidate catalog.

Compare:

A. deterministic composition
B. current System-Two Agent authored Live View
C. bounded decision-model composition

Measure only:

• time to first useful render;
• valid-first-attempt rate;
• semantic usefulness of chosen components/actions;
• number of candidates needed;
• cost;
• failure/fallback behavior.

Do not expand the production component catalog merely for the benchmark.

json-render may be useful prior art or a test implementation, but adopting its runtime is a separate architectural decision.

Experiment 2 — one existing Room App semantic action loop

Prefer an already available Lab fixture or tiny isolated App.

Give one Agent:

small participant projection
+ 5–15 legal semantic actions
+ one high-level goal/strategy

Compare:

scripted policy
vs
System-One policy
vs
System-Two-every-action

Measure:

• action latency;
• quality/reliability;
• visible responsiveness;
• total model cost;
• whether Human↔Agent interaction becomes materially more natural;
• whether mistakes remain bounded by domain validation.

Do not put high-frequency policy traffic through Room DO/history. The App/participant side should own the hot loop.

Experiment 3 — only if 1 or 2 is positive

Test a composite participant Harness:

System Two decides strategy occasionally
→ System One chooses repeated bounded actions
→ strategy refreshes when state meaningfully changes

No generic orchestration framework.

---

Safety / architecture invariants

Preserve all current boundaries:

• Room remains temporary and thin;
• participant owns intelligence/models/tools/credentials;
• Room App remains authoritative for its domain;
• Task Live View remains validated declarative UI;
• arbitrary HTML/JS/CSS remains forbidden in Live View;
• semantic action is not authorization;
• policy output is never trusted merely because confidence is high;
• dangerous/privileged actions still use existing authorization/approval boundaries;
• ordinary local UI actions stay deterministic;
• high-frequency App/policy state must not become DO/history traffic;
• no central planner, global Agent memory or hosted Agent platform;
• Jev-specific protocol must not enter the canonical Room wire format.

A useful rule:

System One may choose among capabilities already allowed by the current authority boundary; it must not create new authority.

---

Falsification / stop conditions

Close this exploration without production work if any of these dominate:

• deterministic rules are simpler for the real workloads;
• useful decisions require so much context that latency/quality advantage disappears;
• System-One errors make interaction visibly erratic;
• System-Two Agent calls are already infrequent enough that there is no user-visible gain;
• model/provider coupling would move participant-owned intelligence into Free4Chat core;
• the App/Live View must expose an excessively large or unsafe action space;
• the experiment is interesting technically but does not improve collaboration.

Negative evidence is a successful result.

---

Current decision

Record the pattern and run no broad integration yet.

The strongest current candidate boundaries are:

Task
→ optional bounded Live View composition

Room App
→ optional fast Agent semantic-action policy

Participant Harness
→ likely owner of System-One + System-Two composition

The immediate goal is to learn where the decision-model boundary is useful and where normal code or the existing System-Two Agent remains better.

If evidence is positive, open one narrow implementation issue for the proven seam rather than turning this research issue into a framework project.

No implementation files or test paths are named. Start with the smallest experiments: compare deterministic, System-Two, and bounded decision-model composition for an existing Task state, then test one existing Lab fixture or isolated Room App with a small projection and legal actions. Done means measured latency, quality, cost, fallback, and boundedness results support a clear boundary decision.