hiloop wants your AI agents to run their own research
A two-person startup out of San Francisco is building the compute layer where agents propose experiments, run them, and prove which one worked. Every run becomes a single, queryable trace.
Most AI teams don't have a data problem. They have a memory problem. An experiment runs, a number moves, and the moment the job finishes the reasoning behind it evaporates - the config, the failed fork, the reason someone tried a cosine learning-rate schedule at two in the morning. hiloop, a company in Y Combinator's Summer 2026 batch, is built around a single stubborn idea: that machine research should leave a record you can trust, and that the machine itself should be able to do the researching.
The company's own description is plain to the point of being blunt. "Hi, we're hiloop," reads the top of its site. "Infrastructure for automated research." Underneath sits the definition that the whole product hangs on: "Autoresearch is agents proposing, running, and verifying experiments." hiloop's job is to give those agents somewhere to do it - snapshottable, forkable compute where observability is built in rather than bolted on afterward.
01 / WHAT IT ISCompute that remembers what it tried
Strip away the framing and hiloop is three things working together. There is compute that agents provision themselves through an API. There is the ability to fork a run - branching the run tree so a new attempt inherits the parent's filesystem straight from a snapshot. And there is observability, where every run is recorded as one trace, with LLM, tool, and stdout events fork-tagged, and tokens and estimated cost rolled up per model. That trace is queryable with SQL, which is a quietly practical detail: research you can query is research you can compare.
Agents spin up their own sandboxes through the API.
Inherit the parent's filesystem from its snapshot.
Abandon an idea, restore any snapshot into a fresh sandbox.
One queryable trace per run, every event fork-tagged.
The fork is the part worth slowing down on. Forking a code repository is ordinary; forking a live experiment - filesystem, state, and all - is not. On hiloop an agent can try an idea, decide it made things worse, restore the parent snapshot, and carry on as if the detour never happened. The company's marketing motif is a "fork-graph," a lineage branching off from main, and it is one of those rare cases where the picture on the website is also literally how the thing works.
$ hiloop run -- claude -p "explain this repo" → capturing run 01K6Z… · every event fork-tagged {"signal":"llm","text":"try a cosine lr schedule, warmup 2k"} {"signal":"exec","cmd":"python train.py --lr cosine","fork":"01K73…"} {"signal":"log","stdout":"step 4000 · val_bpb 0.9021"} {"signal":"llm","text":"worse than parent, restore parent snapshot"} {"signal":"snapshot","op":"restore","to":"01K6Z…"} ✓ one trace per run · every event fork-tagged
02 / THE PROBLEMReproducibility is the whole game
Anyone who has trained a model knows the specific misery hiloop is aiming at. You improve a metric by a point, you can't remember exactly how, and you can't get the number back. hiloop frames its users as teams "where performance is the product," and for them that gap is expensive. Every point of accuracy costs compute, and a result you can't reproduce is barely a result at all.
"If you can measure it, an agent can climb it."
That line does a lot of quiet work. It reframes research as an optimization problem an agent can be pointed at: give it a metric, give it forkable compute, and let it run the experiments a human never had the hours for. The catch has always been trust - letting software execute arbitrary code and touch real credentials. hiloop's answer is to broker secrets, so the agent only ever sees a placeholder and the real key never lands in the sandbox, its environment, or a snapshot. It is the kind of unglamorous safeguard that decides whether autoresearch is a demo or a workflow.
03 / WHO IT'S FORThree kinds of teams
hiloop is candid about who it wants. Not everyone needs forkable research compute - but three groups feel the pain acutely, and the product is shaped around them.
Building autoresearch
Agents propose, run, and verify experiments against a metric you choose.
Training models
Every point of accuracy and dollar of compute counts; reproducibility is non-negotiable.
Performance is the product
Speed, latency, memory, cost - constant iteration that needs a record you can trust.
What ties them together is measurement. If the thing you care about can be turned into a number, hiloop's pitch is that an agent can be set loose to move it, and that you'll be able to see exactly how afterward.
04 / THE DIFFERENCENot a walled garden
The AI tooling shelf is already crowded with experiment trackers and orchestration platforms. hiloop's separation from them is partly technical and partly philosophical. Technically, it pairs forkable, snapshottable compute with tracing that is captured at run time rather than logged after the fact. Philosophically, it refuses to be a closed system. "Bring your own harness, or use ours," the site repeats - and it means it. A homegrown eval script or an off-the-shelf reinforcement-learning loop runs the same way: wrap any command with hiloop run, same provisioning, same traces, no SDK required.
The bet underneath that openness is a view of the market: that the teams which win in AI won't necessarily be the ones with the most GPUs, but the ones whose agents can run the most verified experiments per week. If that's right, the valuable layer isn't the model or the raw compute - it's the plumbing that makes research repeatable. hiloop is choosing to be plumbing on purpose.
05 / THE PEOPLETwo engineers who hit the same wall
hiloop is the work of two founders. Karan Brar, the chief executive, previously worked on machine-learning infrastructure at Reducto, the document-intelligence startup, and led ML infrastructure at DynamoAI, with an earlier stint at BMO Financial Group and a background from the University of Toronto. His co-founder and chief technology officer, Thomas Boser, was a founding engineer at Crosswise and a machine-learning engineer at Discord and SoFi. Between them is a fairly specific résumé: people who have built and babysat ML infrastructure at real scale, and who kept running into the same reproducibility wall.
The company reflects that hands-on origin. It's two people, and they say so. "We read every message and reply ourselves," the site tells prospective users, and the mailing list promises only "a few emails a year" of progress notes to investors, friends, and the curious. It is a small operation making a deliberately large infrastructure claim.
Sometimes the tool you wish existed is the company.
06 / THE MODELHosted, or in your cloud
On business, hiloop is early and not especially coy about it. It sells to teams as infrastructure, and it can run hosted or inside a customer's own cloud - a distinction that matters a great deal to organizations with strict data requirements. Pricing isn't public, and as a two-person YC company its funding beyond the batch isn't disclosed. What's on the table today is the shape of the thing: compute plus observability, deployable where you need it, built for people optimizing something they can measure.
Where hiloop fits, then, is in the widening seam between raw compute providers and the agents that increasingly want to use them without a human holding their hand at every step. Model labs make the models; cloud vendors rent the machines; hiloop wants to be the research system in between - the part that remembers, forks, restores, and proves. It is a narrow position, chosen carefully, and for the teams who live in that seam it answers a real and specific ache.