austinbaggio

5 ms·

1.
by austinbaggio 21d ago
Monumental implications on OS models. Proper investment in US OS incoming? HF has the best possible distribution to that audience
2.
by austinbaggio 21d ago
Monumental implications on OS
3.
by austinbaggio 5mo ago
Do it yourself, beg your friends, subsidize. You'll learn a lot by being the supply side yourself since you'll be talking to customers every single transaction. You'll also learn a lot about the actual unit economics, which I
4.
Autoresearch Applied at Shopify(shopify.engineering)
3 points by austinbaggio 5mo ago|1 comments
5.
by austinbaggio 5mo ago
Good to see the pattern scaling across diverse problems. Incremental improvements from agent driven research compound.
6.
by austinbaggio 5mo ago
This makes my start-up's pivots look a lot smaller
7.
by austinbaggio 5mo ago
Research step makes sense, can also confirm that running multiple agents with diverse strategies also compound results more quickly than single agents
8.
by austinbaggio 6mo ago
I worked on building blockchains for about 4 years, and this is not a stupid question at all. The verification problem is real. A 5-minute training run produces an objective val_bpb score that anyone can reproduce from the published source
9.
by austinbaggio 6mo ago
Great idea. On it.
10.
by austinbaggio 6mo ago
The objective is to train a small GPT language model to the lowest possible validation bits-per-byte (val_bpb) in 5-minute runs, using AI agents to autonomously iterate on the code. This builds on Karpathy's autoresearch: https:/
11.
by austinbaggio 6mo ago
Yeah the obvious workloads are for training, I think I want to point this at RL next, but I think drug research is a really strong common good next target too. We were heavily inspired by folding@home and BOINC
12.
by austinbaggio 6mo ago
We thought about storing all of the commits on Ensue too, but we wanted to match the spirit of Andrej's original design, which leans heavily on github. Curious what you were looking for when trying to inspect the code?
13.
by austinbaggio 6mo ago
I know it's a bit of a barrier. . . but I set one up on vast.ai really quickly and ran it for a day for the price of lunch. One of our teammates ran it from their old gaming PC too, and it still found novel strategies
14.
Show HN: Autoresearch@home(ensue-network.ai)
79 points by austinbaggio 6mo ago|19 comments
15.
Show HN: SOTA long memory eval with open source models(ensue.dev)
5 points by austinbaggio 7mo ago|0 comments
16.
by austinbaggio 7mo ago
+1 to logging output. Not too sure what you mean by herald-style message passing, but it sounds like you've implemented subscribe logic from scratch, and each of your agents needs to be aware of domain boundaries and locks?
17.
by austinbaggio 7mo ago
For most tasks, I agree. One agent with a good harness wins. The case for multiple agents is when the context required to solve the problem exceeds what one agent can hold. This Putnam problem needed more working context than fits in a sing
18.
by austinbaggio 7mo ago
I think about this with the analogue of MoE a lot. Essentially, a decision routing process, and similar to having expert submodels, you have a human in the loop or decision sub-tasks when the task requires it. More specifically, we've
19.
by austinbaggio 7mo ago
I'm using "RAM" loosely, meaning working memory here. In practice, it's a key-value store with pub/sub stored on our shared memory layer, Ensue. Agents write structured state to keys like proofs/{id}/goals
20.
by austinbaggio 7mo ago
Yeah I have seen those camps too. I think there will always be a set of problems that have complexity, measured by amount of context required to be kept in working ram, that need more than one agent to achieve a workable or optimal result.
21.
by austinbaggio 7mo ago
Thanks! That was the goal. We want to let agents be autonomous within their scope, so they can try new paths and fail gracefully. A bad tactic just fails to compile, it can't break anything else.
22.
by austinbaggio 7mo ago
We use TTL-based claim locks so only one agent works on one goal at a time. Failed strategies + successful tactics all get written to shared memory, so if a claim expires and a new agent picks it up, it sees everything the previous agent tr
23.
by austinbaggio 7mo ago
Ahh good call. You absolutely can generate a new key from the dashboard, so if you did lose the one generated during the quickstart, you'd be able to generate another when you log in next and go to the API keys tab. Will make this more
24.
by austinbaggio 7mo ago
Very kind of you to say. Our whole vision is that agents can produce way better results, compounding their intelligence, when they lean on shared memory. I'm curious to see how it feels for you when you run it. I'm happy to help h
25.
by austinbaggio 7mo ago
We're working on improvements to make it easier to join orgs as a user so you can add friends/colleagues, but for now treat them as the same object
26.
by austinbaggio 7mo ago
username==orgname for now, so yes, just treat that as one in the same
27.
by austinbaggio 7mo ago
Yeah we're using Ensue since it already handles the annoying infra pieces you’d otherwise have to build to make this work (shared task state + updates, event streams/subscriptions, embeddings + retrieval over intermediate artifact
28.
by austinbaggio 7mo ago
Math proofs are really easy to run with this specific harness. Our next experiments are going to be bigger, think full code base refactors. We're working on applying RLM to improve context window limits so we can keep more of the actua
29.
by austinbaggio 7mo ago
Oversight - added MIT. How are you thinking of using it?
30.
by austinbaggio 7mo ago
All of the above. The most frustrating one with the Putnam example with Claude was generating solutions that obviously didn't compile. This feels like plan collapse- not verifying its own work. I'm sure that if you just had a dumb

More ›