pancsta

https://github.com/psviderski/unregistry and more in that HN thread.

*CLI MCP server

Reverse proxy in nodejs? How about no?

These are some good points.

I can barely agree with anything in this article.

> most agent systems break down from too much complexity, not too little

...when the platform wasn't made to handle complexity. The main problem is that the "frameworks" are not good enough for agentic workloads, which naturally will scale into complex stateful chaos. This requires another approach, but all that is done is delegating this to LLMs. As the author says "A coordinator agent that managed task delegation", which is the wrong way, an easy exit, like "maybe it will vibe-state itself?".

Agentic systems existed before LLMs (check ABM), and nowadays most ppl confuse what LLMs give us (all-knowing subconscious DBs) with agency, which is a purpose of completing a process. Eg a bus driver is an agent, but you dont ask a bus driver to play the piano. It has predefined behavior, within a certain process.

Another common mistake is considering a prompt (with or without history) an agent. It's just a DB model which you query. A deep research agent has 3 prompts: Check if an answer is possible, scrape, and answer. These are NOT 3 agents - these are DB queries. Delegating logical decisions to LLMs without verification is like having a drunk bus driver. A new layer is needed, which is where all the python frameworks offer it on top of their prompts. That's a mistake, because it splits the control flow, and managing complex state with FSMs or imperative code will soon hit a wall.

Declarative programming to the rescue - this is the only (and also natural) way of handling live and complex systems. It has to be done from the bottom up and it will change the paradigm of the whole agent. I've worked on this exact approach for a while now, and besides handling complexity, the 2nd challenge is navigating through it easily, to find answers to your questions (what and when, exactly, went wrong). I let LLMs "build" the dynamic parts of the agent (like planning), but keeping them in IoC - only the agent layer makes decisions. Another important thing - small prompts, with a single task; 100 focused prompts is better then 1 pasta-prompt. Again, without a proper control flow, synchronizing 100 co-dependent prompts can be tricky (when approached imperatively, with eg a simple loop).

Theres more to it, and I recommend checking out my agents (research and cook), either as a download, source code, or a video walk-through [0].

PS. Embrace chaos, and the chaos will embrace you.

TLDR; toy-frameworks in python, ppl avoiding coding, drunk LLMs

[0] https://github.com/pancsta/secai

By splitting prompts into smaller chunks you effectively get “bias free” opinions, especially when cross-checked. You can then turn them into local reasoning, which is different from “sending an email to the LLM” which seems to be the case here. Remember, LLM is Rainman.

Your question is “how to test opaque nondeterministic databases”. I test my agents deterministically, because I know how to IoC. Check out this code [0] and follow the usage. In the rest of cases, you assert with embeds. Good luck.

[0] https://github.com/pancsta/secai/blob/74d79ad449c0f60a57b600...

For anyone interested, I'm on YC cofounder matching.

When designing interactions with my agents I've added 3 things to the regular chat window: a static list of stories (for mental navigation), a dynamic list of buttons / progress bars (for structured input) and a narrator (kinda a sys-prompt for the user). There's also an interrupt button, as an extra.

I just launched in on HN, take a look:

https://news.ycombinator.com/item?id=44386314

I agree with the debugging part - we need a new approach to handle these abstractions, and a regular code-stepping or reading logs isn't enough in the case of agents. It's all about managing state, and most ppl here say to avoid it. What I say is that if you go all-in and unify the architecture from the bottom layer, it's actually easier in the long run, but you'll need dedicated devtools for that.

This is precisely why I've created AI-gent Workflows (launched on HN today [0]), which comes with a purpose-built state machine and devtools. Unlike LangGraph, it starts already in the lowest layer and everything is state-based. You can time travel and even modify states of a live agent.

[0] https://news.ycombinator.com/item?id=44386314

> automating businesses while documenting the journey comic-style

Where is that documentation exactly?

> specialized AI agents, each with defined roles

Agency is a defined role, by definition.

TLDR; it’s a Key Value DB with TTL. No thinking. Clear mislabeling by the author.

Sway is way more stable, just less eye candy (which is great). Hyperland is practically a fork (wlroots) by a single dev.

I would love to see startup times measured as well.

Nice video logs. Challenge accepted :)

I use searxng, my agent starts a docker compose by itself (embedded fs) and makes it transparent for the rest of the workflow.

Whats the point of agent->sass->search when you can skip the middleman? This is for LLM-only / no local code I guess.

Nim(rod) was released soon before Golang, and the overlap in features probably stopped the former one.

This payment gateway has to be deployed on both ends? And has no exit to fiat? That’s more like internal payments, maybe cost splitting for aigents. You cant book a flight with it, can you?

This isn't a debugger, it's a log viewer. This slidedeck [0] on slides 3 and 4 has a debugger for prompts interacting within a single state machine.

[0] https://www.slideshare.net/slideshow/ai-gent-workflows-demo-...

Id personally appreciate a more complex version of Go, which compiles to plain Go, especially richer types for modeling business logic in places where its beneficial. Your lang may be inspired by Go, but it does not use the Go platform nor toolchain, correct?

You can compile python to WASM, yes. Once you have a *.wasm you can run it anywhere, although the interop with the environment depends on source/destination.

You probably want to run a sandbox for that generated code, eg mocked data, which is bound to your external python calls. WASI is the unified env for real-world APIs.

You should check out secai [0], its a state machine in Golang for long lived agents with structured memory. Its a prerelease and the abstraction of more complex Stories which can intermix will land soon. You can fork the deepreaserch demo and experiment.

[0] https://github.com/pancsta/secai

You mean like Zed? Check their roadmap.

It's nice to see that BEAM is still alive. If you're into actor model / state machine agents, I can recommend secai, which is in Golang [0]. It does have a form of goroutine cancellation. Do you happen to have some screenshots of your devflow in beam? How do you debug?

[0] https://github.com/pancsta/secai

Why not WASM?

Id say thats not model’s responsibility, but a different “part’s of the brain”.

If your nocode tool was a graph, a TUI debugger [0] like this could have helped. The problem is that people usually try to use the graph UI for debugging as well.

[0] http://assets.asyncmachine.dev/video.gif

I totally agree but Id also like to point out that visual debugging on itself is impractical (although cool and easy to pick up). It has its place in education though.

Go is a nobrainer for the listed competition. TS has rich types, but a poor runtime. Theres pretty much no cons to static typing unless youre scripting or your language lacks inference / has types as an option only.

Logfire is a tracing app, an equivalent of Jaeger and other Otel UIs. While I wont discuss reimplementation-vs-integration in this case, traces are just one way of debugging. am-dbg focuses on debugging of the state consensus, instead of the execution tree, without requiring a SaaS account.

Execution trees are enough for workflows, but bots/agents aren't simple workflows.