Research trace unification between persistent pi sessions and Omni.Agent traces.
Key questions to answer:
1) Should we build a compatibility layer on top of pi (translate pi RPC/events into Omni.Agent-compatible traces)?
2) Or should we migrate/extend Omni.Agent to support persistent sessions natively (single runtime + trace model)?
3) Can we build evals that make this choice empirical instead of preference-based?
4) Which path is simpler/safer long term (maintenance, correctness, operability)?
5) How different is pi RPC/event output from Omni.Agent trace/event schema in practice?
Required research outputs:
- Schema diff: field-by-field mapping of pi RPC/events vs Omni.Agent event records.
- Capability matrix: what each model can represent (tool calls, costs, summaries, iterations, errors, stop reasons, multi-turn context, etc.).
- Option analysis:
- Option A: compatibility adapter (pi -> Omni trace)
- Option B: runtime convergence (Omni.Agent persistent sessions)
Include implementation complexity, risk, blast radius, and migration plan.
- Eval plan and prototype:
- Build a small eval harness that runs matched scenarios in both systems.
- Compare trace completeness, determinism, replay/debug usefulness, and information loss.
- Include at least: normal completion, tool-heavy run, failure, interrupted/stop, multi-turn follow-up.
- Recommendation memo with explicit decision criteria and a proposed rollout plan.
Acceptance criteria:
- Written recommendation with evidence from eval outputs.
- Clear statement of the long-term architecture choice and why.
- Follow-up implementation tasks created for the chosen path.