mirror of
https://github.com/hanzoai/papers.git
synced 2026-10-30 14:58:42 +00:00
zeekayandHanzo Dev
1d1e7be5ab
Both report benchmarks that already live in hanzoai/cloud under bench/, so the numbers have a script behind them rather than a spreadsheet. hanzo-dormant-agents takes apart the estimate that costs an agent as a process. State, execution and isolation are separable and differ by five orders of magnitude: a dormant agent is 477 bytes on disk and resumes in 0.034 ms, a parked loop is 601 bytes of heap, and the isolation boundary — the expensive one — is only owed by an agent actually running. The paper argues the container is worth its price where it is needed and says so; the claim is about which agents are charged for it. hanzo-multi-hop-retrieval is a negative result. On LoCoMo a dense retriever finds every required turn for 78.2% of single-hop questions and 22.7% of multi-hop ones, but finds at least one required turn about 80% of the time in both — so it understands the questions and cannot reach all of the answer. Four retrieval policies over one fixed index move that by at most 0.7 points and two make it worse. A diagnostic says why it was never going to work: 95.4% of multi-hop evidence spans sessions and the median worst-ranked gold turn sits at rank 67, so the missing signal is linkage rather than similarity. Publishing the dead end is the useful part. Each paper carries results-data.tex, generated from the runs, and prints XXX in place of any constant that file does not supply — a number cannot drift from its measurement without the drift showing on the page. Both compile under the CI gate's flags, -Werror included. INDEX.md is regenerated by make index, which also picks up the papers added since it was last written and the header its current generator emits. Co-authored-by: Hanzo Dev <[email protected]>
64 lines
3.1 KiB
TeX
64 lines
3.1 KiB
TeX
\section{State at rest: an agent is a row}
|
|
\label{sec:state}
|
|
|
|
A dormant agent's state is whatever it must be handed to carry on: an
|
|
identifier, the tenant it belongs to, its position in a workflow, a pointer to
|
|
its conversation, and whatever the agent itself has stashed. Serialized through
|
|
the production schema this is \rFleetRecord{}\,bytes of JSON for a representative
|
|
agent \meas{}.
|
|
|
|
We wrote \rFleetAgents{} of them --- 100{,}000 tenants with 10 agents each ---
|
|
into SQLite and measured the file.
|
|
|
|
\begin{table}[h]
|
|
\centering
|
|
\begin{tabular}{lr}
|
|
\toprule
|
|
\textbf{Fleet of \rFleetAgents{} dormant agents} & \\
|
|
\midrule
|
|
Agent record, serialized & \rFleetRecord{}\,bytes \meas{} \\
|
|
On disk, per agent & \textbf{\rFleetPer{}\,bytes} \meas{} \\
|
|
On disk, total & \rFleetDisk{}\,MiB \meas{} \\
|
|
Write time & \rFleetWriteS{}\,s \meas{} \\
|
|
Write rate & \rFleetRate{}\,agents/s \meas{} \\
|
|
Resume, in-process & \textbf{\rFleetResume{}\,ms} \meas{} \\
|
|
Resume, via process spawn & \rFleetResumeCold{}\,ms \meas{} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\caption{State residency. The gap between the serialized record and the on-disk
|
|
figure is SQLite's per-row and index overhead: \rFleetPer{} against
|
|
\rFleetRecord{} is 110\,bytes of structure per agent, which buys the index that
|
|
makes the resume in the last row possible.}
|
|
\label{tab:fleet}
|
|
\end{table}
|
|
|
|
Three things in that table matter more than the headline.
|
|
|
|
\paragraph{The whole fleet fits in a file you can copy.}
|
|
\rFleetDisk{}\,MiB is smaller than a single container image. It fits in page
|
|
cache on the laptop it was measured on. There is no storage tier involved and no
|
|
distributed system: it is one file, and the standard tools work on it. This is
|
|
what makes the dormant majority cheap --- not a compression scheme or a tiering
|
|
policy, but the absence of anything that would make it expensive.
|
|
|
|
\paragraph{Writing is not the bottleneck anyone expects.}
|
|
\rFleetRate{}\,agents/s means the entire million-agent fleet is created in
|
|
\rFleetWriteS{}\,seconds on one core of a laptop. A platform provisioning agents
|
|
at even a thousand a second --- which would be a very busy platform --- is using
|
|
0.3\% of the write path measured here.
|
|
|
|
\paragraph{Resume is cheap enough to prefer over residency.}
|
|
\rFleetResume{}\,ms in-process is the number that settles the design question.
|
|
If bringing an agent back from a row costs 34 microseconds, then holding its
|
|
execution context alive to avoid that cost is only worth it for an agent that
|
|
will be woken again within microseconds. For anything idle longer --- which is
|
|
what dormant means --- the row is strictly better: it costs \rFleetPer{}\,bytes
|
|
of disk instead of \rGoPer{}\,bytes of RAM, and it survives a restart.
|
|
|
|
The contrast in the last row is worth stating plainly. Resuming through a cold
|
|
process spawn costs \rFleetResumeCold{}\,ms, which is 100$\times$ the in-process
|
|
figure. That entire 100$\times$ is process creation, not agent work. It is the
|
|
first appearance in this paper of the pattern that dominates the rest of it:
|
|
\emph{the cost is almost never the agent, it is the container the agent was put
|
|
in.}
|