Hi HN! Hrishi from Southbridge here.

Long story short: we needed something to actually do brownfield agentic engineering with: something that made it easier to reason about what an agent will see in context at any point in time, remove and flush context often, clear handoffs, better primitives.

Something we noticed is that LLMs have started co-evolving with their harnesses - anthropic gets more training data from you using claude code, claude code gets new features from claude first, etc etc - so we decided to change the base primitive from the llm call to the agent loop. almost any harness - codex, opencode, etc - is supported, you just need to generate a shim using one of the hanks like we do.

So we ended up building a runtime that executes sequenced AI programs - blocks of prompts and code that get loaded into context, run, monitored and then torn down.

We’ve been using it for a while, open-sourcing it in case its useful. Maybe it’s our visibility set but there’s not much out there focused on reliable executions and doing less so you can think more.

It’s single agent threaded (no parallel agent things), designed for headless (we’re a data company), no MCP or skills things - our general policy has been ‘build what you NEED’ and we just haven’t EVER needed those things.

Have fun!

Read more about the idea behind it here: https://southbridge.ai/hankweave

Love this!

Thanks for all the feedback! I've added a section at the end addressing as many as I can.

I like buttons too. Quite a fair bit. But when you get to too many buttons, they become icons.

Add that to the fact that all user tests we've done have fared better with search and more verbose interfaces, and I wonder if we are both of us far from the target user profile.

Good catch - fixed!

That's a good point at the end, and where we'd like to be. Unfortunately dev time is always a finite resource, especially for an early-stage product. You need to pick one over the other - at least a little.

> Unfortunately dev time is always a finite resource

true, but usually not the limiting factor.

more to the point; money is a finite resource if the product is intended to generate a profit.

Some of our inspiration definitely comes from CAD, NX CAD and Fusion. IMO the work they've put into making a mountain of functionality useful and intuitive to a new user has paid off.

And that's the functionality in front and planned to be favored by users. Many older features are available to those who know how to ask for them.

Also, in terms of the geometry, how the system builds models, the feature version is stored with the features, and that version will build models in newer software, until migrated forward by a user.

It's very complex.

Thanks for this! We're definitely working it into our system. It's always good to have multiple paths when possible, so a menu that connects to search and backwards might be quite useful to introduce users to features, but tie in muscle memory once they are used to it.

We're guilty of this, despite caring about the product and the users. It's hard to focus on maintenance and deep iteration when there's more critical (and cool) functionality to chase. Not to mention that iterative UX improvements have the same problem as negative results in academia - it's hard to get people excited about it.

I've used the UK verify service, and it was pretty horrible then. Only country I've seen do it somewhat well is Singapore, with Singpass.