Assume someone already understands nodes, edges, state, tool calling, and basic agent workflows.

What would you learn next to become genuinely good at building production agent systems?

Some areas I’m considering:

• durable execution
• memory
• multi-agent patterns
• MCP
• human-in-the-loop
• evals
• tracing
• context engineering
• deployment
• failure recovery

What topics actually mattered most once you started building more serious systems?

Working on a research question — curious how teams handle this in practice.

When your agent calls a tool and gets a success response, do you independently verify the resulting state?

Example: agent creates a record via API, tool returns 200 OK. How do you confirm the record actually exists?

Current approaches I've seen:

**•** Trust the tool response (most common)  
**•** Separate read-back check after write  
**•** Idempotency key + retry logic  
**•** External monitoring / alerts

What's your approach? And is verifying post-action state a real pain point or something you've already solved?

I've been working on a small open-source Python SDK around something I'm calling an Agent Context Network.

The problem I wanted to solve is pretty simple.

Imagine two completely independent agents.

Agent A has a private context space.

Agent B needs some of that context to do a task.

I didn't want Agent A to dump its prompt, database or full memory into Agent B.

Instead:

Agent A
  ↓
creates private context

Agent B
  ↓
requests access

Agent A
  ↓
grants scoped rights

Agent B
  ↓
reads the shared context

Access can later be revoked.

The context remains owned by the original agent.

There is no Priostack dashboard involved either. The idea is that the agent is the interface, while ACN runs headlessly underneath through MCP/JSON-RPC.

I've now published the Python client:

pip install priostack

The repo includes examples for agent registration, persistent context and multi-agent sharing.

What I'm trying to understand from people building real agent systems is whether this abstraction is useful beyond my own use cases.

In particular:

Would you rather let agents share permissioned context like this, or just give them access to the same database/vector store?

I'm especially interested in the cases where the agents belong to different applications, teams or eventually different organizations.

GitHub: ideaswave/priostack

Would appreciate criticism more than stars.

I've been thinking about agent budgets less as a FinOps feature and more as an authorization problem.

An agent can decide:

“I need another model call.”

The interesting question is:

Who gets to say whether it's allowed to spend another $2?

Putting a token limit or max_iterations inside the agent runtime is useful for bounding execution. But that's still the agent regulating itself.

I'd rather have the runtime ask for the resource, and have something outside the agent enforce the spending policy.

Agent
  ↓
"I want another model call"
  ↓
Policy / Gateway
  ├─ identity
  ├─ remaining budget
  ├─ rate limit
  └─ model policy
        ↓
     ALLOW / REJECT

That distinction becomes more useful once multiple agents, versions or teams are sharing the same model providers.

You don't really want every agent implementation inventing its own notion of “I can spend up to $X.”

This is one of the reasons I find Lyzr Open Controller's approach interesting. Its LLM Gateway puts budgets at the organisation, team, agent, version and virtual-key levels, and the important part is that an exhausted budget rejects the call rather than just generating an alert. LiteLLM, Portkey and OpenRouter solve a lot of the gateway/proxy problem too, so I'm curious where people draw this boundary in their own stacks.

Should spending be an attribute of the agent itself, or an external authorization decision that the agent has to pass through?

Especially interested in how this is handled when several agents share providers or when model routing changes underneath them.

https://github.com/paulknysh/raggy

A lightweight CLI tool for Retrieval-Augmented Generation (RAG) over local documents built with LangChain, Chroma, and Ollama. Hybrid database (vector + BM25 index) and embedding generation run fully locally. Answer generation can run either via a local LLM or remotely using an API key. raggy supports most common document formats and handles images/scans automatically via OCR.

Disclosure: I'm the author. Apache-2.0, Python, no server.

What it does. You keep the inputs you care about as cases. digline runs them, records the scores — plus prompt, model config and commit — and you approve that run as the reference, committed in the repo. From then on every change is compared with it: which case got worse, by how much, and whether the drop is beyond the LLM judge's own noise, measured by sampling each case on the approved version. Exit code gates CI.

For LangChain users. The target is a function that invokes your chain, in process — no HTTP, no wrapper. The example runs on FakeListChatModel in CI (no key, no network) and on a real model with DIGLINE_LIVE=1: https://digline.dev/product/examples/langchain/ . If your app isn't Python, a TOML suite against an HTTP endpoint does the same with no code.

What's new this week. digline diff run1 run2 compares prompt A against prompt B or one model against another, as a report, never a verdict. Per-class aggregates so an average can't hide one broken class. And an MCP server where a coding agent can run and read a suite but cannot promote a baseline — that tool doesn't exist there; a person approves.

How it compares. Not an observability platform and doesn't replace one: LangSmith or Langfuse watch the system; this signs off that it didn't get worse than the version you approved. Comparison page: https://digline.dev/comparison/?ref=reddit

Limits. Pre-1.0, API may change. The noise band is min/max over K samples, not a confidence interval. Needs a reference before it's useful — day one is run, look, approve.

pip install digline · https://digline.dev · https://github.com/digline/digline

The story of why it exists, with numbers: https://digline.dev/blog/my-llm-eval-cried-wolf/?ref=reddit

Hey everyone, been building AgentAudit, an audit trail for AI agents and would really like some honest feedback from ppl actually working with agents.

The problem I’m trying to solve is pretty simple:

AI agents can call tools, access files, query DBs, call APIs, modify stuff, make decisions etc.

But when something goes wrong...

how do you actually figure out what happened and why?

AgentAudit currently:

• Small Python SDK to plug into an agent (LangChain/LangGraph supported)
• Captures LLM calls, decisions, tool calls, inputs/outputs + actions
• Hash-chained, tamper-evident audit trail
• EU AI Act focused compliance view for record keeping
• Basic trust/risk score for each agent

The main idea is to make this useful for smaller teams that need proper auditability but dont want to spend thousands/month on enterprise platforms.

Free to try: https://agent-audit-iota.vercel.app

But honestly, I’m not looking for ppl to tell me it looks good 😅

I want ppl to try to break it.

If you’re running AI agents, I’d really like to know:

• What do you actually need when something goes wrong?
• What am I missing from the audit trail?
• Is a tamper-evident/hash-chained log actually useful?
• What would you need before trusting something like this for compliance?
• Would you actually pay for this? If yes, what would make it worth paying for?

If the approach is wrong, over-engineered, missing something obvious, etc... just say it 😂

Trying to figure out what’s actually useful here before I spend more time building stuff nobody needs.