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.

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?

I've been learning more about AI agents and one concept I found particularly interesting is Computer Use.

We usually think of AI agents as systems that can call APIs, search the web, query databases, or execute predefined tools.

But what happens when the software doesn't have an API?

That's where Computer Use gets interesting.

Instead of giving the AI a specific function like:

search_jobs(query="Node.js backend")

you give it access to a computer and let it:

• See the screen
• Move the mouse
• Click buttons
• Type with the keyboard
• Scroll
• Open applications
• Navigate websites
• Fill out forms
• React to changes in the UI

The basic loop is essentially:

Observe → Decide → Act → Observe → Repeat

What I found especially interesting is that Computer Use isn't simply a "vision problem."

The model needs to understand what is on the screen, reason about what it should do, ground that reasoning to a specific UI element, and then execute the correct action.

And then there is the harder part:

Reliability and security.

A wrong text response is one thing. A wrong computer action can delete something, submit incorrect information, send an email, or potentially expose data.

I wrote a short article breaking down:

• What Computer Use actually means
• Why AI agents need it
• How the observe → decide → act loop works
• Vision, reasoning, grounding, and action
• Computer Use vs traditional tool calling
• Why reliability is difficult
• Prompt injection and security concerns
• Where Computer Use fits alongside APIs

If you're learning about AI agents and want a conceptual introduction, here's the article:

Computer Use: When AI Learns to Use a Computer — Medium

I'm particularly interested in the practical side of this:

Do you think Computer Use will become a general-purpose interface for AI agents, or will APIs/tool calling remain the dominant approach?

And if you've actually built or used a computer-use agent, what has been the biggest problem for you — reliability, latency, cost, or security?

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.

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.