Hacker Timesnew | past | comments | ask | show | jobs | submit | amavashev's commentslogin

True website is not for you and in the age for AI is not even for people. Its for AI agents reading your website and deciding what to do with it: recommend it, skip it, integrate with it, etc.


Yes more and more this will be the case. Websites will not be for people, because most people don't go to websites for the experience, they go there for information. And if a smart search engine can show them what they need to know without actaully showing the website, that's good enough in most cases.

You can stop worrying about layout, styles, colors, fonts, responsive design... just put the information on a page so that AI can understand it.


The no proxy approach makes sense for LLMs calls. The gap is non LLM calls.

Often times damage is done by non LLM calls -- tool calls like sending email, add records, files, placing order, etc. Budget enforcement at the LLM layer wont work for those.

built an open protocol + reference implementation, handles both any tool calls, LLM calls, or any other call: https://runcycles.io, open sourced under Apache 2.0


Agree, you need to your own code review, although as AI gets better, this problem will most likely be solved.


The core argument here is that autonomous agents will need a economic envelope enforced before execution not after.

This means agents must follow this flow: reserve, use, commit or release.

Interesting how others are handling runaway agents, loops, etc, especially under concurrency.




I'm the author. A few design decisions worth explaining:

The model downgrade is the most useful feature for daily use — when budget drops below a threshold, the plugin silently swaps claude-opus to claude-sonnet, gpt-4o to gpt-4o-mini. The agent keeps running, just cheaper. Only at full exhaustion does it stop.

The prompt hint (before_prompt_build hook) tells the model its remaining budget in the system prompt. Models self-regulate when they know the constraint exists — fewer unnecessary tool calls, shorter responses.

The underlying Cycles protocol handles idempotency under retries so concurrent tool calls don't double-spend against the same budget.

Happy to answer questions about the plugin or the protocol.


Per-key isolation + model locking is a solid baseline — especially for multi-tool stacks where one shared key hides everything.

One thing we’ve noticed though: spend caps stop damage, but they don’t prevent pathological behavior. By the time the cap trips, the agent has already drifted.

We’ve been experimenting with pre-authorization per action (reserve → commit style) rather than just per-key ceilings. It lets you detect anomalous patterns before the burn accumulates — especially in looping or tool-chaining scenarios.

Curious — have you seen most overruns come from loops, retries, or just high-token completions?


Drift correlating more with constraint tension than raw step count matches what we’ve observed.

Your external gate instinct is right, but the gate has to be structurally external, not just logically external. If the agent can reason about the gate, it can learn to route around it.

We’ve been experimenting with pre-authorization before high-impact actions (rather than post-hoc validation) - I've drafted Cycles Protocol v0 spec to deal with this problem.

What’s interesting is that anomalous reservation patterns often show up before output quality visibly degrades — which makes drift detectable earlier.

Still early work, but happy to compare notes if that’s useful.


>...if the agent can reason about the gate, it can learn to route around it.

This is especially true. Earlier iterations of our build had python backed enforcement modules in an accessible path. The agent would identify the module that was blocking completion and, instead of fixing the error, it would access the enforcement module and adjust the code to unblock itself.


This is exactly the point where agent design starts to look less like workflow automation and more like control theory.

If the agent can inspect or mutate the enforcement layer, then the enforcement layer becomes part of the optimization surface. At that point you’re not solving drift, you’re creating an adversarial environment where the agent optimizes around constraints.

That suggests the real boundary isn’t logical separation, it’s capability isolation. The agent shouldn’t just fail validation, it shouldn’t even have the representational access required to reason about how validation works.

We’ve been experimenting with isolating enforcement in a separate execution layer with scoped pre-authorization for high-impact actions. When the agent can’t model the gate, routing-around behavior drops significantly, and drift shows up first in reservation or planning instability rather than surface output errors.

Still early exploration, but it’s becoming clear that “better prompting” is the least interesting part of this problem.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: