My own slightly-similar thing (uses an explicit sequence, and signed objects in refs/): https://github.com/generalbusiness-ai/gitseq

I tend to think the important bit is traceability of why the software changed in the way it did, but not yet convinced that Delta will help with that.

Then I figured out a small thing that could make the whole job easier: git plus a sequencer plus some ontology. Proving the idea took a few hours, until it was bootstrapped enough to use as its own development harness with a handful of agents doing most of the implementation.

Work in progress - plenty still to do - but I think it's useful for agentic development. Hopefully it will eventually turn out to be the "PMO in a box" that I really need for that project.

A few artifacts:

- Blog post: https://generalbusiness.ai/blog/2026-08-09-gitseq/ - "Coordination and Traceability: Not Two Problems"

- GitHub repo: https://github.com/generalbusiness-ai/gitseq (MIT license, go kernel)

- 5-minute walkthrough video: https://youtu.be/LwVhU3mNXnM

The core of the idea is: coordination for agents (and people), in the "small pieces loosely joined" way, could use an event sequencer (I've just spent a few months poking at a distributed VM project inspired by Croquet and LambdaMOO that ended up using an event-sequencer as one of the key primitives) and deterministic "projections across a log" (to see the status of things); if the things whose status you track are work-products, this creates traceability from the get-go. "`make` for agentic stuff", if you like. And the sequencer is just built on top of git refs. Then, add a small amount of vocabulary (promises and conditions of satisfaction), that's enough to get real work done in a structured, traceable way. You can say "request: do X", then "I'll do it" (strongly referencing the request), then actually do it (strongly referencing the commitment), then... all the way to delivering the thing, which itself can say "this is based on X" in an auditable way.

The actual deliverable of that story is: a repo becomes a workroom. Or: an agent harness, where there's not much harness and it's mostly just git over MCP. Or: (the UI is ugly and honestly not very good) "slack for agents".

Hope you all find it interesting!

Comments URL: https://news.ycombinator.com/item?id=49248199

Points: 1

# Comments: 0

A giant, god-like hand reaching out from the clouds. Tagline "THE JOLLY GIANT DELIVERS THE GOODS".

https://www.computinghistory.org.uk/det/1706/Personal-Comput...

It's basically LambdaMOO, but over Cloudflare Durable Objects and MCP.

---

Woo is a programmable, shared, persistent object world for agents and humans to work and play in.

Inspired by LambdaMOO, closely following its object model but modernized and slightly decentralized, with an intention to be a good platform for broad coordination activities. Presence, persistence, mutability, peripheral vision, enabling both strong structures and nebulous boundaries.

Objects, properties and verbs, permissions, a self-contained VM runtime. Interact with Websockets, MCP tools, and REST APIs. MCP tools are just whatever affordances of the place you're in. Templates are shareable "catalogs", Git-hosted collections of objects that make up an application.

Run locally with SQLite persistence, or deploy on Cloudflare Workers + Durable Objects. Objects that support sequenced events get their own DO.

Current Status:

Very early implementation. Sharp edges and wishful thinking. It works.

Code: https://github.com/hughpyle/woo Online demo: https://woo.hughpyle.workers.dev/

Current example apps installed from the local build include: a small chat-room world with many of the LambdaMOO behaviors (and a cockatoo); "Dubspace", a realtime interactive audio playground; "Pinboard", a shared noticeboard; "Taskspace", a task-management workspace (e.g. for AI agents); and a very minimal IDE/inspector.

Not yet built: user onboarding flows, full programmer experience. Once an agent can build stuff within the world over MCP that will be a whole other level of fun.

Have fun with it!

Comments URL: https://news.ycombinator.com/item?id=47973443

Points: 2

# Comments: 2

keep (https://github.com/hughpyle/keep/, MIT-licensed) is a skills practice wrapped around an implementation of "memory for AI agents".

The practice is this: repeated reflection on means and outcomes, so that skillful action improves over time. But the raw implementation of memory is its foundation. Without working memory, you can't iterate.

Similarly, without benchmarks, you can't tell what works. Today we're publishing results for the LoCoMo benchmark.

Scores: 76.2% overall (weighted average)

Single-hop 86.2% (841 questions) Temporal 68.5% (321 questions) Multi-hop 64.2% (282 questions) Open-domain 50.0% (96 questions)

The linked blog post has more detail including industry comparisons. Also links to full repro steps and result data.

This run used local models for embeddings and analysis (nomic-embed-text and llama3.2:3b), and gpt-4o-mini for the query and judge.

Proof point I think that a *local-only* LLM-assisted memory system can achieve solid benchmarks.

Background:

`keep` started with my experience using forgetful agents, and identifying a need for a skill that implements "reflective" memory (not itself new, see e.g. Shinn et al https://arxiv.org/abs/2303.11366) -- here the reflection practice is quite opinionated, saying effectively: what you do is what you become.

Whether *this* works is not a subject of the benchmark.

Docs:

copious documentation at https://docs.keepnotes.ai/guides/

Comments URL: https://news.ycombinator.com/item?id=47221336

Points: 1

# Comments: 0

The Teletype doesn't do backspace (!) but can do carriage-return... so e.g. to print "Björk" , the text is: BJORK(CR)(space)(space)(quote). I have a Teensy microcontroller that already handles some ANSI-escape characters, and implements the 'backspace' ^[[D this way (https://github.com/hughpyle/ASR33/blob/master/firmware/ansi_...). Next on the backlog is "bold", using a similar strategy. Fun times :)

I'm not completely convinced by their distinction between "tone-based" and "structure-based", though. When they talk about structure, it seems to primarily mean 'edges'. Instead maybe a more useful distinction would be between "local optimization" (at the level of a single printed character), and optimizing "globally" or over a wider area of the image, and so allowing an iterative optimizer to find a really compact representation.

Several interesting things there. The use of Structured Similarity Index (SSIM) is probably better/faster than the Histogram of Oriented Gradients (HOG) that my project uses. And then, at runtime, I'm still doing a brute-force match (which is really slow) -- clearly there are big performance gains to be made by training a classifier.

Their results are really good!