I've been playing with this for the past 24 hours or so. I like the atomic containment of the LLM, and the clear separation of logic, code, and prompts.

You have some great working examples, but, for example: translate_text specifies the default language in three places: the card, the input schema, and the deck. This can't be necessary; I'll experiment, but shouldn't it just be defined in one place?

The descriptive language of the project is a bit dense for me too. I'm having a hard time figuring out how to do basic things like parameters -- let's say that I want to constrain summarize_text to a certain length... I've tried to write language in the cards/decks, but the model doesn't seem to be paying attention.

I also want to be able to load a file, e.g. not just "translate 'hello my friend' to Italian" but "translate '/test/hello_my_friend.txt' to Italian" and have it load the contents of the file as input text. How do I do that?

Super cool project!

This is interesting. What resonated for me is how much effort you’re putting into making the execution graph explicit.

In my experience, a lot of agent failures don’t come from the harness or the model choice, but from authority and assumptions leaking across steps. Once agents stay “alive” too long, it gets hard to tell which decision was made under which constraints.

I ran into similar issues experimenting with step-gated workflows using GTWY.ai. What helped was forcing each step to declare its inputs, tools, and outputs up front, and then dropping all of that before the next step ran. The system felt less clever, but debugging and reliability improved a lot.

Curious how you’re thinking about permission and context lifetimes as agents call other agents. That boundary is where things got subtle for me.

You might want to know that Gambit is an open source Scheme implementation that has been around a very long time.

nice work. the idea of breaking agents into short-lived executors with explicit inputs/outputs makes a lot of sense - most failures i've seen come from agents staying alive too long and leaking assumptions across steps.

curious how you're handling context lifetimes when agents call other agents. do you drop context between calls or is there a way to bound it? that's been the trickiest part for us.

Is this an alternative to https://mastra.ai/docs

How would it compare?

We ran into similar reliability issues while building GTWY. What surprised us was that most failures weren’t about model quality, but about agents being allowed to run too long without clear boundaries.

What helped was treating agents less like “always-on brains” and more like short-lived executors. Each step had an explicit goal, explicit inputs, and a defined end. Once the step finished, the agent stopped and context was rebuilt deliberately.

Harnesses like this feel important because they shift the problem from “make the model smarter” to “make the system more predictable.” In our experience, reliability came more from reducing degrees of freedom than from adding intelligence.

also, it seems like this works with openrouter, and perhaps OpenAI -- what about Gemini API?

[under-the-rug stub]

[see https://news.ycombinator.com/item?id=45988611 for explanation]

[flagged]