Agent harness for Pi and Orca

The problem

I work with several agents at once, and the harness that launches them had ended up consuming more resources than the agents themselves. Two symptoms: the machine was heating up and the response felt slow.

What I did

Instead of optimising by eye, I measured. A V8 profile of 10,628 samples showed that the render loop was hogging more than 80 % of the time and that the process was idle 0.6 % of it. That was not “slow”: it was a badly built path being walked continuously.

The second finding was more interesting. Every session spun up its own tree of TypeScript language servers, and each one consumed around 1.1 GiB resident. The memory I was seeing did not come from the agents; it came from the tools’ infrastructure.

After the fix, idle time went up to 74 % and a synthetic component benchmark dropped from 284 milliseconds to 9. The important part is what the document does not claim: that this is not a 31× improvement of the application, that resident memory is not shared and therefore exaggerates consumption, and that I do not attribute the temperature drop to this change.

Why I show it

Because it is the only project where the deliverable is a diagnosis. I did not build a new tool: I understood why one I used was slow, fixed it, and wrote down what my own measurement does not prove.

That last part is the one that almost never gets written and the one that separates a technical report from a sales report.

Besides, the project documents a real fight with someone else’s architecture: I wanted to unify two agent environments and it could not be done, because both register the same family of tools and the host rejects duplicate providers. The conclusion was to accept two environments and document why, which is less elegant and more useful than forcing the unification.