Comparison
UHP vs Agent Trajectory Interchange Format (ATIF)
UHP standardizes how a client executes work through a complete agent harness. ATIF standardizes how an agent run is recorded as portable structured trajectory data. They are complementary layers, not competing runtime protocols.
The one-sentence difference
Section titled “The one-sentence difference”UHP is a live execution contract between a client and a server that runs complete harnesses; ATIF is a JSON interchange format for recording what happened during an agent run so the trajectory can be inspected, evaluated, replayed or used in training pipelines.
The two therefore sit on different sides of execution: UHP drives work; ATIF serializes execution history.
Status first
Section titled “Status first”- UHP is
2026-08-11, a Draft standard with a runnable 52-check conformance suite (2026.8.11.post1). - ATIF is an Active Harbor RFC whose current changelog is
v1.7. The RFC is dated April 2026 and defines the Agent Trajectory Interchange Format as Harbor’s standardized JSON logging methodology for complete autonomous-agent interaction histories. - ATIF is not an IETF, ISO or UHP specification. Calling it an interchange format or active Harbor RFC is more precise than implying formal standards-body status.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | ATIF |
|---|---|---|
| Primary boundary | Client/product ↔ UHP server ↔ complete harness runtime | Agent/runtime or observer ↔ trajectory document ↔ evaluator/replay/training consumer |
| Main purpose | Execute and control harness work consistently | Record complete agent interaction history in a portable structured form |
| Data model | Harnesses, responses, sessions, containers, files, artifacts and events | Agent metadata plus ordered steps, messages, reasoning, tool calls, observations, metrics and optional subagent trajectories |
| Live control | Submit, stream, continue and cancel work | No invocation or cancellation API; it describes recorded execution |
| Session identity | Server-owned response/session lifecycle | session_id is run-scoped; v1.7 adds trajectory_id for per-trajectory identity and subagent-reference resolution |
| Tool activity | Exposed through UHP task/events/files according to the server contract | Tool calls and observations can be serialized directly into trajectory steps |
| Multi-agent representation | UHP does not define a general multi-agent trace interchange format | v1.7 supports embedded subagent_trajectories and explicit subagent references |
| Evaluation/training | Conformance verifies UHP server behavior; UHP does not define an SFT/RL trajectory dataset format | Designed for debugging, visualization, replay, evaluation, SFT and RL pipelines |
| Authentication/authorization | Normative UHP server authentication and object-scoping requirements | Data format; does not replace runtime authentication or authorization |
| Maturity snapshot | Draft protocol with reference implementation and conformance suite | Active Harbor RFC, current changelog v1.7; implemented by NVIDIA NeMo Relay exporters |
What ATIF records
Section titled “What ATIF records”The current RFC models a trajectory as an ordered sequence of system, user and agent steps. Depending on what the producer captures, those steps can include:
- messages and explicit reasoning content;
- structured tool calls and correlated observations;
- model and token/cost metrics;
- continuation references when a run is split across trajectory files;
- multimodal content references;
- embedded subagent trajectories and per-trajectory identifiers;
llm_call_count, including deterministic orchestration steps where no LLM call occurred;- copied-context markers so training consumers can distinguish prior context from newly produced interaction data.
That schema is intentionally about trajectory evidence, not about how an agent process is started or controlled.
Why this matters for harness interoperability
Section titled “Why this matters for harness interoperability”Agent-harness portability has at least two separate interoperability problems:
- Execution interoperability: a product needs one way to submit work, stream progress, continue sessions, cancel work and retrieve artifacts across complete harness runtimes. UHP targets this layer.
- Trajectory interoperability: evaluators, observability tools and training pipelines need a common representation of what happened inside or around a run. ATIF targets this layer.
A system can therefore use both. A UHP server or the harness behind it could, in principle, emit an ATIF record after or during a UHP-driven run, while the client continues to use UHP for runtime control.
Independent implementation evidence
Section titled “Independent implementation evidence”NVIDIA NeMo Relay provides an ATIF exporter that collects runtime lifecycle events and converts them into trajectories conforming to the ATIF v1.7 schema. Its documented mapping turns LLM lifecycle events into user/agent steps and correlates tool completion with observations. This is concrete implementation evidence for ATIF beyond the Harbor RFC itself.
The Harbor RFC also compares ATIF’s schema needs with trajectories from systems such as MiniSweAgent, OpenHands and Gemini CLI. That comparison is design input, not proof that those upstream projects natively emit or adopt ATIF.
Security and data-handling boundary
Section titled “Security and data-handling boundary”ATIF can contain high-sensitivity execution data: prompts, reasoning content, tool calls, observations, file/path references and model metrics. Portable trajectory interchange can improve auditability and evaluation, but it can also widen the blast radius of captured secrets or private context.
UHP’s authentication, per-principal object scoping and server data-handling responsibilities therefore remain separate concerns. Exporting a UHP-driven run to ATIF would require an implementation-specific policy for redaction, retention, access control and storage; ATIF does not inherit UHP authorization merely because both formats describe the same run.
What ATIF does not replace
Section titled “What ATIF does not replace”- It does not replace UHP’s client-to-harness execution contract.
- It does not define harness discovery, model selection, task submission, streaming or cancellation.
- It does not turn a trajectory producer into a UHP implementation.
- It does not establish native UHP adoption by Harbor, NVIDIA or any harness whose trajectory shape informed the RFC.
- It does not itself prove that two harnesses behave equivalently; it gives evaluators a common record format in which to compare their runs.
Related pages
Section titled “Related pages”Read UHP architecture, UHP lifecycle, UHP conformance, the ecosystem map, and UHP vs ACP for neighboring execution, lifecycle, evaluation and client-integration boundaries.