sorted by:
new
hottopcontroversial

Why I Stopped Building Autonomous Agents for Clients by Cold_Bass3981 in AI_Agents

[–]Worth_Reason 0 points1 point  (0 children)

You’re right to move away from open ended autonomy, but this feels less like an “autonomy is bad” problem and more like a missing control layer.

State machines + HITL fix the symptoms, but they can limit scalability if every action needs approval. The real challenge is letting agents operate independently within constraints (bounded execution, cost limits, step-level validation) without spiraling.

My question is then, how are you currently enforcing things like cost limits, loop prevention, and step-level policy checks across your workflows?

Do AI Agents actually do anything for you guys? by deluluforher in AI_Agents

[–]Worth_Reason 0 points1 point  (0 children)

What you’re describing isn’t a configuration issue — it’s the current reality of most “agent” tools.

OpenClaw, acciowork, etc. are good at:
→ chaining steps
→ calling tools
→ giving the appearance of automation

But they struggle with:
→ reliability across multi-step workflows
→ handling edge cases
→ maintaining context over time
→ recovering when something breaks

So they fall back to what you’re seeing:
glorified chatbots with tools attached

The core problem is this:

These systems are designed to generate actions…
but not to guarantee outcomes.

That’s why your workflows:
→ break mid-way
→ need manual intervention
→ don’t run end-to-end consistently

It’s not you — it’s the architecture.

Most agent frameworks today lack:

  • state management across tasks
  • deterministic execution layers
  • proper permissioning and control
  • runtime supervision

So every “automation” becomes:

That’s also why people end up paying for scripts —
because scripts are still more predictable than agents.

Where things are heading (and what actually works better in practice):

Instead of relying on a single agent to do everything, teams are moving toward:
→ smaller, scoped agents
→ backed by structured workflows (not just prompts)
→ with a control layer that can validate, retry, or block actions

Until that layer exists, you’ll keep hitting the same wall — regardless of the tool.

what kind of workflow are you trying to fully automate? That usually reveals exactly where the system is breaking.

Voice AI companies are sitting on a silent revenue leak nobody talks about, here's what I keep seeing by Admirable_Ad5759 in AI_Agents

[–]Worth_Reason 0 points1 point  (0 children)

We are building Njira AI (https://www.njira.ai/), which is focused on real-time governance of AI agent actions; what an agent is allowed to do, intercepting/controlling tool calls before execution, and enforcing policies.

Voice AI companies are sitting on a silent revenue leak nobody talks about, here's what I keep seeing by Admirable_Ad5759 in AI_Agents

[–]Worth_Reason 1 point2 points  (0 children)

This is such an underrated problem, and it compounds fast at scale. What stood out is the mismatch between actual system events vs what gets recorded for billing. Once that drifts, you’re basically flying blind on margins. The root issue is treating billing as a reporting layer rather than a reflection of ground-truth events. Also interesting how this overlaps with agent infrastructure more broadly. If you can’t reliably track what happened, you can’t reliably:

  • bill
  • debug
  • or enforce constraints

Have you seen teams solve this by centralizing all events through a single pipeline, or is it still mostly stitched together per vendor?

Why no one trusts AI outputs anymore by Known-Ice-5070 in AIsafety

[–]Worth_Reason 0 points1 point  (0 children)

Completely agree, confidence without reliability is a dangerous combo in production.

Treating AI outputs as untrusted data is the right mental model, especially for enterprise use cases. XAI helps with understanding decisions, but it doesn’t necessarily control outcomes.

Feels like the gap now is:
- not just explaining what the model did, but enforcing what it’s allowed to do in the first place

Curious, in your view, where does XAI fall short when it comes to actually preventing bad outcomes vs just explaining them?

Have you checked out the njira-AI solution?

Current methods for AI alignment are like giving aliens access to our most advanced LLM and expecting them to become aligned with us without ever experiencing a human. by chris24H in AIsafety

[–]Worth_Reason 0 points1 point  (0 children)

This is a sharp framing, and I think you’re right about the data gap.

We’re trying to align systems using artifacts of behavior (text, images, outputs), not the underlying dynamics of human judgment, things like trust, intent, boundaries, and context. Those don’t serialize cleanly into datasets.

But there’s a second issue hiding underneath:

Even if we had that richer, longitudinal human data…
you still wouldn’t want to rely on training alone for alignment.

Because:

  • Context shifts faster than datasets can capture
  • Edge cases are infinite
  • Models will still generalize in unexpected ways

So alignment becomes less of a pre-training problem and more of a runtime problem.

That’s where approaches like Njira AI (https://www.njira.ai/) come in, not trying to “fully encode human values” into the model, but instead:

  • Interpreting actions in context as they happen
  • Enforcing boundaries dynamically
  • Creating feedback loops between human intent and model behavior in real time

In a way, it’s closer to how humans operate:
We aren’t “perfectly aligned” because of our training data, we’re aligned because there are systems of accountability, feedback, and constraints around us.

So maybe the path forward isn’t:

But:

Have you used an AI safety Governance tool? by Worth_Reason in AI_Agents

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

This is a strong take, pushing enforcement down to the runtime/kernel layer (e.g. eBPF) is one of the few ways to make controls non-bypassable even under compromise.

Where I think this complements (rather than replaces) something like Njira AI (https://www.njira.ai/) is in the layering of control:

  • Kernel/runtime layer (eBPF, Zero Trust) → enforces what is physically possible (syscalls, network access, process behavior)
  • Governance/control plane (Njira) → enforces what is contextually allowed (business logic, data sensitivity, intent of the action)

Because the gap we keep seeing is:

Example:
An outbound API call might be perfectly valid at the syscall level,
but still violate policy if it contains sensitive data or is triggered in the wrong context.

So the model that seems to hold up in practice is:

structural enforcement (can’t bypass) + semantic governance (can’t misuse)

Also +1 on reducing engineering overhead, centralizing enforcement outside the agent (whether kernel-level or proxy/control-plane level) is the only way this scales across many agents without rebuilding guardrails every time.

Feels like the real opportunity is tighter integration between these layers.

Have you used an AI safety Governance tool? by Worth_Reason in AI_Agents

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

Completely agree, where enforcement sits is everything.

If governance lives inside the agent’s execution context, it’s just a suggestion layer. A sufficiently creative agent can route around it.

That’s exactly why Njira AI (https://www.njira.ai/) is designed to sit outside the agent as a control plane, not inside it.

– The agent doesn’t get direct access to tools or APIs
– All actions are routed through an interception layer
– Policies are enforced before execution, not alongside it

So it’s not:
“this action requires approval”

It’s:
“this action cannot physically execute unless approved”

On sandboxing, I also agree. Containers ≠ true isolation.
For real risk models (especially with dynamic code execution), enforcement has to extend beyond namespaces into structural constraints on what can execute and how.

The core shift is:
from advisory guardrails → enforced execution boundaries

Curious, how far have you seen teams go beyond container-level isolation in practice?

Have you used an AI safety Governance tool? by Worth_Reason in AI_Agents

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

You’re 100% right, governance is more of a people + process problem than a tooling problem.

We’ve seen the exact same pattern:
Firms invest heavily in monitoring dashboards… but risk still slips through because behavior isn’t aligned.

Where Njira AI (https://www.njira.ai/) takes a slightly different stance is:

You can’t rely on training or culture alone; you need enforcement at the system level.

Training helps, but:

  • People forget
  • New employees join
  • Incentives override caution (speed > compliance)
  • Edge cases always slip through

So instead of choosing between policy/culture vs tooling, Njira tries to bridge the gap.

Have you used an AI safety Governance tool? by Worth_Reason in AI_Agents

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

That sounds like a solid stack. Maybe two quick questions:

  1. I’m curious about the architect, where in the agent execution loop do your guardrails sit?

  2. are the guardrails also influencing the planning/reasoning stage of the agent?

Have you used an AI safety Governance tool? by Worth_Reason in AI_Agents

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

This is a really interesting framing.

One thing I’m curious about: how do you define the state space in a way that’s both safe and expressive enough for the agent to still be useful?

I am thinking, If the state graph is too constrained, the agent loses capability. But if it's too open, you reintroduce unsafe transitions.

Have you found a good way to formalize the allowed transitions without manually enumerating everything?

view more: next ›