| ▲ | pancsta 4 days ago |
| Very informative wiki, thank you, I will definitely use it. So Ive made my own "AI Agents framework" [0] based on actor model, state machines and aspect oriented programming (released just yesterday, no HN post yet) and I really like points 5 and 7: 5: Unify execution state and business state
8. Own your control flow
That is exactly what SecAI does, as it's a graph control flow library at it's core (multigraph instead of DAG) and LLM calls are embedded into graph's nodes. The flow is reinforced with negotiation, cancellation and stateful relations, which make it more "organic". Another thing often missed by other frameworks are dedicated devtools (dbg, repl, svg) - programming for failure, inspecting every step in detail, automatic data exporters (metrics, traces, logs, sql), and dead-simple integrations (bash). I've released the first tech demo [1] which showcases all the devtools using a reference implementation of deepresearch (ported from AtomicAgents). You may especially like the Send/Stop button, which is nothings else then "Factor 6. Launch/Pause/Resume with simple APIs". Oh and it's network transparent, so it can scale.Feel free to reach out. [0] https://github.com/pancsta/secai [1] https://youtu.be/0VJzO1S-gV0 |
|
| ▲ | serverlessmania 3 days ago | parent | next [-] |
| "Another thing often missed by other frameworks are dedicated devtools" From my experience, PydanticAI really nailed it with Logfire—debugging[0] agents was significantly easier and more effective compared to the other frameworks and libraries I tested. [0] https://ai.pydantic.dev/logfire/#pydantic-logfire |
| |
| ▲ | pancsta 10 hours ago | parent [-] | | 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. |
|
|
| ▲ | dhorthy 4 days ago | parent | prev | next [-] |
| i like the terminal UI and otel integrations - what tasks are you using this for today? |
| |
| ▲ | pancsta 4 days ago | parent [-] | | Thanks, terminal UI is an important design choice - it's fast, cheap, and runs everywhere (like the web via wasm / ssh, or on iphones with touch). The LLM layer is still fresh, and I personally use it for web scraping, but the underlying workflow engine is quite mature and ubiquitous - it was used for sync engines, UIs, daemons, network services. It shines when faces complexity, nondeterminism, and retry logic - the more chaotic the flow is, the bigger the gains. The approach is to shape behavior from chaos by exclusion, instead of defining all possible transitions. With LLMs, this process could be automated and effectively an agent would be dynamically creating itself using a DSL (state schema and predefined states). The great thing about LLMs is being charged by tokens instead of a number of requests. We can just interrogate them about every detail separately and build a flow graph with transparent (and debuggable) reasoning. I also have API sketches for proactive scenarios (originally made for an ML prototype) [0]. [0] https://github.com/pancsta/secai/blob/474433796c5ffbc7ec5744... |
|
|
| ▲ | wfn 4 days ago | parent | prev [-] |
| This is great, thank you so much for sharing! |
