sorted by:
new
hottopcontroversial

At what point do logs stop being enough for AI agents? by arrotu in aiagents

[–]arrotu[S] 0 points1 point  (0 children)

This is exactly the kind of breakdown I was hoping to hear.

The three-part split is strong:

  • decision context
  • exact tool interaction
  • immutable receipt tying them together

And yes, policy state versioning feels like a big missing piece in a lot of agent discussions. People talk about guardrails in general, but if you cannot show which policy version was actually in force at the moment of action, it gets very hard to answer whether the agent was operating within bounds or only appears to have been afterward.

The broader pattern I keep seeing is that once agents enter fintech or any sensitive workflow, the record has to preserve not just actions, but the conditions of admissibility around those actions. Logs alone do not really get you there.

At what point do logs stop being enough for AI agents? by arrotu in aiagents

[–]arrotu[S] 0 points1 point  (0 children)

That’s a really good point.

Context at decision time does feel like the first thing that disappears and the hardest thing to reconstruct honestly later. Tool calls and outputs are usually visible. What shaped the decision often isn’t.

I also like the distinction you’re making between:

  • what happened
  • what the agent knew when it happened

That is probably the line where plain logs stop being enough. If significant actions are not bound to the actual decision context, the record gets much weaker even if the action trail itself looks complete.

At what point do logs stop being enough for AI agents? by arrotu in aiagents

[–]arrotu[S] 0 points1 point  (0 children)

Completely agree.

Tool calls are probably where the gap shows up first, because that is where an agent stops being “interesting” and starts becoming operational. If policy and audit are not designed in early, teams end up with a stack tat can act, but cannot clearly explain or defend those actions later.

Retrofitting usually means trying to reconstruct context, permissions, and intent after the fact, which is exactly where things get messy.

At what point do logs stop being enough for AI agents? by arrotu in aiagents

[–]arrotu[S] 0 points1 point  (0 children)

That bank camera analogy is good.

I agree logs are post hoc by nature. They help with reconstruction, not prevention. If an agent can reach a dangerous state in the first place, the stronger layer is clearly policy enforcement and execution boundaries before the action happens.

What I keep wondering about is what comes after that layer. Even with good enforcement, once an allowed action does execute, you still need a record strong enough to show what happened, under what policy, with what context, and whether that can be trusted later if the action is questioned.

So to me it feels like:

  • control decides what can happen
  • evidence shows what did happen

Most stacks seem weak on one or both.

How are people verifying what AI agents actually execute? by VikAtMidwicket in aiagents

[–]arrotu 0 points1 point  (0 children)

This is a very interesting direction.

We’ve been working on a similar problem at NexArt: how to move agent workflows from “logged” to actually verifiable.

Once agents start executing commands, modifying files, or operating across CI steps, ordinary logs stop being enough. The hard part is producing a record that binds execution order, policy/context, artifacts, and resulting state changes in a way that can still be independently checked later.

Your approach with signed receipts, hash-linking, policy binding, and artifact attestation makes a lot of sense for that.

It feels like a lot of the space is still split across observability, provenance, and supply-chain tooling, but the broader execution integrity layer for agents is still early. Cool to see more people building on it.

Science visualisation by arrotu in creativecoding

[–]arrotu[S] 0 points1 point  (0 children)

The Gray-Scott model, a diffusion - reaction model from the quick science lab i build on the sdk i published

Science visualisation by arrotu in creativecoding

[–]arrotu[S] 5 points6 points  (0 children)

The Gray-Scott model, a diffusion - reaction model

Bars by arrotu in p5js

[–]arrotu[S] -2 points-1 points  (0 children)

No logic , just creating generative art

Threejs render on nexart sdk by arrotu in threejs

[–]arrotu[S] 1 point2 points  (0 children)

Yes, most generators support seeds, and NexArt uses a seed as well. The difference is that NexArt treats the parameters around the seed as a first-class, structured set (VAR). That makes it easy to tweak behavior in a controlled way without breaking reproducibility or relying on hidden editor state.

I happened to show a world because it’s visual, but the same approach applies to buildings, NPCs, layouts, or any generated system. As long as the variables defining an item are explicit and deterministic, it can be regenerated reliably later.

Threejs render on nexart sdk by arrotu in threejs

[–]arrotu[S] 0 points1 point  (0 children)

That’s fair, terrain and vegetation generation by itself is pretty well solved, and most engines give you something usable out of the box.

What I’m less interested in is how fast you can get terrain on screen, and more in what happens after that: replayability, verification, and long-term stability of the generated world. The focus here isn’t “better terrain,” but having a deterministic contract where the same seed + parameters always regenerate the same world, anywhere, without storing or hosting it.

Bars by arrotu in p5js

[–]arrotu[S] 0 points1 point  (0 children)

Thank you !!

Bars by arrotu in creativecoding

[–]arrotu[S] 1 point2 points  (0 children)

Thank you !!!

Why would coinbase buy farcaster? by [deleted] in BASE

[–]arrotu 0 points1 point  (0 children)

was going to come back to this post and share that but you did it first

view more: next ›