"Each conversation is writing an invisible roadmap you need to materialize". 100%. Most teams treat observability as a checkbox, not a product feedback loop.
Interesting take on building your own orchestration layer. What's the core advantage you're seeing with Adama over existing frameworks? Curious if you've hit any walls with reliability or if the control trade-off is worth it.
I'm just getting started to be honest. I freaked out when I realized how much I was spending with OpenClaw for the conversations. Right now, I'm building tools that integrate AI, and I'm going to continue down this route.
The crazy thing is that i had ralph analyze all my existing documentation and blogs (which never got any traction), and it told me I was barking up the wrong tree but that my platform would be great with AI agents. So, I'm very new to this whole space, but it is fascinating.
Really like the framing of "Time to Accountability" as the bottleneck. Curious how you think about this for the orchestration layer specifically. A lot of agent frameworks give you observability into the graph. You can see which node fired, what tools were called. But the reasoning that led to those decisions is still opaque. Is the answer better tracing/logging of model decisions? Or more constrained orchestration logic?
Cost attribution gets even worse when you factor in the bad decisions. Retries, abandoned tool calls, and cascading failures that still hit your bill but never show up in traces.
I’m building an OTel-based SDK that wraps the billable edges (entrypoint, LLM/tool clients, async publish/consume) and emits both traces for debugging and a lightweight event ledger for run/attempt lifecycle and call boundaries. I define the workflow + possible outcomes up front, then attribute all runs and attempts to the final outcome event to get the cost per outcome
The 'you can review code you can no longer write' line is so real. That's the gap that sneaks up on you. Easy to miss until you're three layers deep in something you merged last week.
Context compression is necessary but it's treating symptoms, not the disease. The core issue is that most agent architectures bolt long-horizon reasoning onto models that weren't designed for it. Summarization, filesystem offloading, etc. are clever workarounds, but you're still fighting the model's tendency to lose the thread. Curious if anyone's seen approaches that handle context at the inference layer rather than patching it in the orchestration layer.
Interesting approach. Curious how you think about the tradeoff between external memory systems vs. models that manage their own context natively. It feels like the industry is split on which layer should own this.
Thanks. We think that while short term memory can be handled by LLMs directly and can be commoditised, it would be harder to do that natively for long term memory. We write about it in our article: https://medium.com/versanova/understanding-memory-in-ai-agen...
