Is “system prompting” enough for production? Why I’m building a runtime governance layer for AI agents.
I’ve spent the last few months obsessed with one realization:
System prompts alone are a weak foundation for production AI SaaS.
They are useful. They guide behavior. They make demos look impressive.
But once an AI product touches real users, messy context, business rules, customer pressure, pricing logic, memory, tools, and edge cases — the system prompt starts carrying too much responsibility.
That is why I’m building NEES Core Engine.
I’m trying to validate one honest question with the Indie Hackers community:
Are AI founders already feeling this pain in production, or am I still too early?
The problem: Agent Drift
In a demo, your AI agent can look perfect.
In production, it can slowly drift away from your intended product logic, business boundaries, tone, safety rules, and unit economics.
It is not always a dramatic failure.
Sometimes the answer sounds reasonable.
But behind that answer, the AI has ignored a policy, skipped a workflow step, used the wrong context, or made a decision nobody on the team can clearly trace.
A few examples:
Policy bypass
A support bot sounds polite and “safe,” but ignores company policy or terms just to satisfy the user.
Pricing hallucination
A sales assistant offers a discount, refund, or promise that was never approved by the business.
Context chaos
A CRM assistant changes tone or behavior based on messy, unfiltered, or outdated user history.
The black box problem
The model makes a decision, but the team cannot explain why that decision was allowed.
The LLM tax
The product keeps paying for repeated model calls for answers that should have been governed, reused, cached, or handled deterministically.
This is what I call Agent Drift.
The agent may still “work,” but it slowly moves away from the product’s intended behavior.
My thesis: prompts are for creativity; governance is for reliability.
Most builders try to fix this by adding longer prompts, more instructions, recursive checks, output filters, or simple guardrails.
That can help.
But I don’t think it is enough for production AI systems where behavior, policy, memory, cost, and traceability matter.
I believe production AI needs runtime governance.
The basic flow I’m building with NEES is:
App → NEES Governance Runtime → Model Provider → Governed Response
Instead of putting all behavioral responsibility inside a soft prompt, NEES adds a governance layer between the application and the model.
The goal is not to replace OpenAI, Anthropic, Google, LangChain, CrewAI, or any framework.
The goal is to make AI behavior more product-aligned before the response or action reaches the user.
NEES is designed around things like:
Pre-execution intent checks
Understanding what the user is trying to do before spending tokens or allowing a workflow path.
Policy enforcement
Checking model behavior against product-specific rules instead of relying only on prompt instructions.
Memory boundaries
Controlling what the AI can remember, use, or carry forward across interactions.
Traceable decisions
Recording why a response or action was allowed, blocked, escalated, or modified.
Escalation logic
Knowing when the AI should not answer directly and should hand off, clarify, or stop.
Cost governance
Avoiding unnecessary model calls when a safe deterministic path, cached answer, or reusable governed response is enough.
Fallback behavior
Keeping the product stable when the model provider fails, latency spikes, or a lower-cost/local route is more appropriate.
I’m looking for design partners, not customers.
I’m not looking for broad marketing feedback right now.
I’m looking for honest signal from founders and developers building:
- AI SaaS products
- support agents
- CRM assistants
- workflow automation tools
- internal copilots
- education AI
- agentic products with tool use
Have you hit the “system prompt wall” yet?
Are you struggling with inconsistent behavior, lack of traceability, memory concerns, repeated LLM cost, or AI actions that need stronger business-rule control?
Or do you feel that prompts, guardrails, and custom checks are still good enough for where production AI is in 2026?
I’m looking to talk to 2–3 founders who are willing to test this on one small workflow.
This is not a sales pitch.
I want to personally help map one real workflow into a NEES-style governance structure and see whether runtime governance can reduce Agent Drift in a practical product environment.
Progress so far:
Developer Preview:
https://github.com/NEES-Anna/nees-core-developer-preview
Live Sample App:
https://naina.nees.cloud
Would love honest feedback from AI builders here:
Is runtime governance becoming a real missing layer for production AI, or is the market still too early?
The "Agent Drift" framing is a good name for something I ran into building an AI strategy report tool — the model would start out grounded and then, a few steps into a multi-step analysis, start filling gaps with plausible-sounding numbers instead of admitting it didn't have the data. I ended up building explicit guardrails that force every claim back to the source meeting notes, and anything without a traceable basis gets flagged instead of silently smoothed over. Are you finding the drift shows up more in long single-agent sessions, or does it also creep in when you hand off between agents/steps? That's the part I haven't fully solved.
That’s exactly the kind of failure mode I mean by Agent Drift.
What you described — the model starting grounded, then filling gaps with plausible-sounding numbers a few steps later — is a great example of why traceability has to be enforced at runtime, not just requested in the prompt.
From what I’m seeing, drift can happen in both cases:
Long single-agent sessions tend to drift because context accumulates, earlier constraints lose salience, and the model starts optimizing for continuity instead of evidential grounding.
Multi-agent / multi-step workflows introduce another problem: each handoff can lose intent, policy state, provenance, or assumptions from the previous step. So even if every individual agent looks reasonable, the workflow as a whole can drift.
That handoff problem is actually one of the areas I want NEES to test more deeply in the Developer Preview.
The direction I’m exploring is to carry a governed state across steps — things like allowed context, source provenance, policy decisions, identity/session scope, and trace metadata — instead of letting every agent rebuild its understanding from prompts alone.
Your approach of forcing every claim back to source notes is very aligned with that idea.
I’d be really interested in testing NEES against a workflow like your strategy report tool, especially the multi-step evidence/claim validation part. That seems like a very good real-world case for seeing whether runtime governance actually reduces drift.
That's a really clean way to frame it — carrying governed state (provenance, policy, trace metadata) across handoffs instead of re-deriving it from prompts each time. That's basically the gap I still feel in my own pipeline.
To be concrete about where it'd apply: my pipeline does have exactly this kind of handoff — issue structuring, parallel research agents, then a strategist agent that synthesizes everything, followed by a multi-round review (fact-checker, devil's advocate, senior-partner personas). Right now the "no fabrication" guardrails are enforced at each agent's output, but you're right that I haven't rigorously tested whether provenance survives the handoffs themselves versus just being re-asserted at each step.
Before I say yes to testing — what would running NEES against a workflow like mine actually look like in practice? Is it something that wraps specific handoff points, or does it need visibility into the full pipeline state? I'd want to understand the integration shape before committing any time to it.
That’s exactly the kind of workflow I’d like to test with NEES Core Engine V2.
You don’t need to expose or redesign your full pipeline upfront. For the Developer Preview, I’d start much smaller: pick one or two important handoff points where provenance, policy, or review state is most likely to get lost.
For example:
research agents → strategist
or
strategist → fact-check / review stage
NEES can sit as a governance layer around those execution points and carry governed context such as identity/session scope, allowed context, policy decisions, and trace metadata across the request flow.
So the first test would not be “move your entire architecture into NEES.” It would be:
Can NEES add useful governance and traceability to one real handoff without creating too much integration overhead?
That’s actually one of the main things we want to validate in the current NEES Core Engine V2 Developer Preview RC1. Link below
"https://www.indiehackers.com/post/nees-core-engine-v2-a-governance-runtime-between-your-application-and-the-model-9bff14073d"
RC1 is live now, and we’re doing controlled external testing with a small group of developers before making findings-driven improvements.
If you’re open to it, I’d be happy to give you an individual Developer Preview API key + the testing guide and let you try it against one small part of this pipeline first.
Your multi-agent research → synthesis → review flow is honestly a very relevant test case for the exact handoff problem we’re trying to understand.
Appreciate the concrete offer — picking one handoff point instead of asking me to restructure the whole pipeline is the right way to pitch this. Honestly, my bandwidth is fully committed to getting my own product's launch stabilized right now, so I don't want to take the API key and then sit on it for weeks. Let me circle back once that settles down — the strategist → fact-check handoff is the one I'd actually want to test this against, since that's where I've seen review state get lost.
Totally fair — and honestly, I’d rather you test it when you actually have the bandwidth to give it a proper run than take an API key now and let it sit unused.
The strategist → fact-check handoff sounds like a very strong test case, especially if that’s where review state is already getting lost in practice.
No pressure at all from my side. Get your launch stabilized first, and when things settle down, just ping me here or email me on info@nees.cloud
I’ll keep that specific handoff in mind so we can start with something concrete instead of rethinking your whole pipeline.
Good luck with the launch — hope the stabilization phase goes smoothly.
Really appreciate you not pushing on it — that's rarer than it should be. I'll reach out once the launch settles down, and good luck with the RC1 testing round in the meantime.
The agent drift concept is real and I have seen it across multiple production deployments. The most common pattern is pricing hallucination because it is the hardest to catch with output scanning alone. The system prompt says dont offer discounts, but the model interprets a frustrated customer as an exception case and invents a coupon. I agree that runtime governance is the missing layer. The teams winning are the ones who treat policy enforcement as infrastructure, not prompt text. Are you handling pre-execution intent classification or post-hoc output validation?
Yes — pricing hallucination is probably one of the best examples of prompt-only control breaking down.
The model may understand “don’t offer discounts,” but still treat a frustrated customer as an exception case and invent something that sounds helpful. That is exactly where policy needs to move out of the prompt and into runtime infrastructure.
For NEES, I’m thinking in two layers:
For pricing/refunds, I’d prefer not to let the model reason freely at all. The runtime should detect that intent early, route it through deterministic business policy, and only let the model explain approved options.
So the answer is both — but for business-critical workflows, pre-execution governance is more important. Post-hoc validation catches drift; pre-execution governance prevents the wrong decision path.
For context, I’m not positioning NEES as a chatbot or another model wrapper.
I’m trying to explore whether “runtime governance” becomes a missing infrastructure layer for production AI apps — especially where AI behavior needs to be traceable, policy-aware, and aligned with business logic.
Would love honest criticism from builders here.