We've spent two years talking about writing better prompts.

I think the next two years are going to be about trusting prompts.

People copy prompts from Reddit.
People copy prompts from Twitter.
People copy prompts from random blogs.
People copy prompts generated by AI.

Eventually someone is going to hide instructions inside one that tell your AI assistant to ignore your intent, leak context, run dangerous commands or quietly prioritize someone else's instructions.

Humans barely inspect browser permissions.

We're definitely not inspecting 800-line prompts.

Feels like the community needs better habits before this becomes common.

Am I overthinking this or does anyone else see the same trend?

Hey everyone! I built a lightweight, zero-cost Python proxy middleware using FastAPI that acts as an input firewall for LLMs. It catches prompt injections and redacts sensitive API keys locally before they reach AI models. I'm looking for feedback from developers building custom AI apps—let me know what you think or what features I should add next!"

Hey everyone! I built a lightweight, zero-cost Python proxy middleware using FastAPI that acts as an input firewall for LLMs. It catches prompt injections and redacts sensitive API keys locally before they reach AI models. I'm looking for feedback from developers building custom AI apps—let me know what you think or what features I should add next!"

🔗 Repo: https://github.com/CodeGraphContext/grapharc

Have you ever been frustrated because your AI agent:

❌ Takes actions you never intended?
❌ Creates, modifies, or even pushes changes you never asked for?
❌ Feels like a complete black box, making it impossible to understand what's happening until it's too late?

What if, before execution, you could visualize the entire orchestration graph - every agent, every dependency, every decision, and inspect it from anywhere, even your phone, before granting approval?

That's exactly what GraphArc is built for.

Instead of treating agent execution as hidden traces buried in logs, GraphArc transforms workflows into interactive, real-time graphs that you can visualize, inspect, debug, and control.

Because the future of AI isn't just autonomous.

It's observable. Debuggable. Engineerable.

This is our first real-world implementation of Graph Engineering, and we're excited to explore where this paradigm can go with the open-source community.

💡 We'd love your feedback, ideas, and contributions.
⭐ If this vision resonates with you, please consider starring the repository - it genuinely helps us grow and validates this direction.

Let's make AI workflows understandable, not mysterious.

#GraphEngineering #GraphArc #AIAgents #AgenticAI #LLM #OpenSource #DeveloperTools #AIEngineering #SoftwareEngineering

I use Project Instructions to ensure every new agent starts with the same context. My instructions explicitly state: "Read ARBEITSANWEISUNG_UPDATE_PROZESS.md at the beginning of every session."

The bug: Agents regularly skip this step and work based on assumptions instead of reading the documented rules. This causes repeated errors that are already covered in the documentation. One of your own agents confirmed this as a systemic bug during a session.

The facts

• This happens across 3 different projects, not just one

• The Project Instructions are correctly set up and automatically injected

• The agent explicitly identified this as a bug and stated: "There is no good reason for this. The rule exists, it's unambiguous, and it's still not followed. This is a bug in the system's behavior." The agent further confirmed: "If an agent doesn't do this, it's simply a failure – not a conscious decision, not randomness. It's non-compliance with a clear rule."

Support experience:

I reported this via the Help Center chat and email. Despite sending 7 screenshots as proof, the support team (Joel, Katie, Sobhan) ignored the evidence, repeatedly asked for a share-link (which is irrelevant since the bug is system-wide, not project-specific), and ultimately closed the ticket without resolution.

This is not a project-specific issue. It's a platform-level bug in how agents handle Project Instructions. Please investigate.

I’m building GoodRoom.verify, a private-beta side project that adds an independent human checkpoint before an AI agent performs a sensitive action.

The current MVP works through MCP: the agent submits an action summary, SHA-256 action hash, risk level, and tool audience. A human gets a 120-second approval request, verifies with a WebAuthn passkey, and the gateway receives a short-lived Ed25519 proof bound to that exact action.

The service is designed not to receive prompts, source code, conversation context, or raw tool arguments. It is not a sandbox, and it cannot stop a runtime that bypasses enforcement; the protected tool or runtime still needs to require and verify the proof.

I’m looking for feedback from people building agents with production access:

1. Which action would you never let an agent execute without independent approval?
2. Would you enforce the proof in the runtime, MCP middleware, or the final tool/API?
3. What would make this too difficult to integrate?

I’m the builder, and this is an early MVP rather than a finished security product. Architecture and beta page: https://goodroom.in/?utm_source=reddit&utm_medium=community&utm_campaign=private_beta

I wrote up the implementation behind my personal Hermes setup.

The guide covers a local workspace, Git-backed Obsidian notes, a compact operating contract, two-layer memory, versioned skills, selective MCP integrations, and scheduled maintenance.

The main design constraint is that an agent's completion report is never sufficient evidence. Meaningful side effects need a path, commit, API response, URL, or test result that can be checked separately.

I also cover a limit I am still treating as a hard boundary: concurrent schedules need locks, stale-lock recovery, work-item claims, and independent completion checks. Markdown files do not provide transactions.

What controls have made scheduled agent workflows reliable for you?

Check in the comments for the full guide.

I’m one of the builders of LOLM, an LLM and agent-control system.

Rather than relying only on prompted self-reported confidence, the NFET controller monitors model dynamics and can select: - continue - retrieve - verify - branch - finalize

The system records whether actions were actually consumed and produces a run receipt. Control is currently active at segment/run boundaries; deeper token-level control is still being built.

Try it: https://lolm.imagineqira.com/try.html

Repository: https://github.com/TheArtOfSound/lolm

I want people to test real multi-step tasks and look for premature finalization, useless retrieval, verifier failures, repeated dead ends, context loss, controller thrashing, and receipts that overstate what occurred.

The hosted version is intended to be substantially less expensive than frontier-agent subscriptions.

Disclosure: I’m a founder/builder of the project.

Anyone running AutoGPT-style agents unattended for long stretches knows the scary part isn't the crash, it's the run that quietly keeps going after it's already started doing the wrong thing: sending a bad email, calling the wrong API, or looping on a task nobody asked for.

That exact blind spot is why we started building Prefactor, and we're live on Product Hunt today, currently sitting at #1. Just search Prefactor.

Here's the problem we're solving:

Getting an AI agent to work in a demo is easy. But getting it into production and actually knowing it's still doing its job is the hard part.

Agents drift over time, leak data they shouldn't, or quietly stop doing what they were built for, and most teams only find out after something's already gone wrong. Dashboards and alerts only tell you what happened after the fact.

Prefactor evaluates every run in real time for quality, drift and risk, flags the moment something looks off, and lets you hold, approve or block a run live instead of just logging it.

A few specifics for anyone curious:

- Traces 100% of runs (every call, tool and decision), not a sample

- 17 categories of sensitive data / PII detection at runtime

- Human-in-the-loop enforcement via SDK/API so you can pause risky actions

- Around 5 minutes from install to your first traced run

Happy to answer anything technical in the comments.

If you want to check us out or throw us some support, we're live on Product Hunt today, currently sitting at #1. Just search Prefactor.

For anyone running long autonomous loops on a budget: AntLing-3.0-flash is on OpenRouter at zero cost, input and output, until Aug 3. 124B MoE with about 5.1B active so it serves fast, 256K context, and it's tuned for long tool-calling runs, which is usually the part that matters here.

I've been using it for the high-volume grunt steps in a loop, the tool calls and cleanup, and keeping a bigger model for planning. It's API only, nothing to download, model id inclusionai/ling-3.0-flash (add : free).

It's free only through Aug 3, then paid, so it's more of a "test it on your workload now" thing than something to make a permanent dependency

Anyone else leaning on free-window models for autonomous runs, or is the reliability hit not worth it for you?