News for hackers. Stuff that matters.

thesvp

This is exactly the right mental model. "Language is soft, infrastructure is hard" is the core insight most teams miss until they've been burned. The Unix escalation analogy is spot on.

We've been building in this space and the pattern we keep seeing is teams implement exactly what you described, then hit a wall when they have 3+ agents, or a new engineer joins, or they want to audit what happened across 10,000 agent runs last week.

What we built is essentially the infrastructure layer you're describing, but as a centralized control plane. Same primitives (structural constraints, escalation rules, audit-first for irreversibles), but portable across agents and visible to the whole team.

Curious — are you managing these identity files manually per agent, or do you have a system for it?

we're building the platform that manage all policies of the agent

check out our launch post https://news.ycombinator.com/item?id=47146354

Show HN: Limits – Control layer for AI agents that take real actions

https://limits.dev

Prompt instructions like 'never do X' don't hold up in production. LLMs ignore them when context gets long or users push hard.Limits sits between your agent and the real world. Every action — database writes, API calls, refunds — gets intercepted and checked against your rules before it executes. Deterministically. No LLM involved in enforcement.Three modes:Conditions: hard rules on structured...

( Read More... | 2 comments | 7 points | on HN )
6 months and 1100+ receipts to get to useful patterns — that's the hidden cost nobody talks about. The governance layer is 'boring' but it's also 6 months you're not spending on the actual agent. That feedback loop from receipts to dispatch quality is exactly what we're building as infrastructure so teams don't start from zero.
Understanding intent and following instructions are different failure modes. LLMs are good at the first, unreliable at the second. That's exactly why enforcement lives outside the LLM.
Sandboxed execution is solid for isolation — separating proposal from execution is the right architecture. The piece we kept hitting was the policy layer on top: who defines what the agent is allowed to propose in the first place, and how do you update those rules without a redeploy every time?
Fair. We didn't choose LLMs to enforce rules — we chose them to understand intent. The enforcement happens outside the LLM entirely. That's the separation that actually holds up in production
The separation between 'what the agent wants to do' and 'what it's allowed to do' is the right mental model.

The append-only ledger point is underrated too — pattern data from real failures is worth more than any upfront rule design.

How long did it take to build and maintain that governance layer? And as your agent evolves, do the rules keep up or is that becoming its own maintenance burden?

Exactly right - the deterministiclayer is the only thing you can actually trust.

We landed on the same pattern: LLM handles the understanding, hard rules handle the permission. The tricky part is maintaining those rules as the agent evolves. How are you managing rule updates code changes every time or something more dynamic?

Ask HN: How are you controlling AI agents that take real actions?

We're building AI agents that take real actions — refunds, database writes, API calls.Prompt instructions like "never do X" don't hold up. LLMs ignore them when context is long or users push hard.Curious how others are handling this: - Hard-coded checks before every action? - Some middleware layer? - Just hoping for the best?We built a control layer for this — different methods for structured...

( Read More... | 22 comments | on HN )