NEES Core Engine V2 a governance runtime between your application and the model.
We just reached Developer Preview RC1 for NEES Core Engine V2, and I’m looking for a small group of developers to test it in real-world AI products.
The problem we’re trying to solve is something many AI builders eventually run into:
LLM APIs are easy to call, but production behavior gets messy fast.
You start dealing with things like:
- inconsistent AI behavior
- no clear trace of why a response happened
- identity or memory leakage between users/sessions
- prompt injection risks
- provider logic spread across the app
- rising token and inference costs
- governance rules being rebuilt again and again
NEES Core Engine V2 is designed as a governance runtime between your application and the model.
It helps with:
- runtime policy enforcement
- identity and memory boundaries
- governed provider execution
- governance metadata and traceability
- safer behavior handling
- context and cost governance
The RC1 baseline is already live and verified across authenticated /chat, provider execution, health/readiness, governance metadata, and trace flow.
At this stage, I’m not looking to add more core features.
I want developers to integrate it, push it into edge cases, and tell me:
What works?
What breaks?
What feels difficult to integrate?
What would make it more useful in a real product?
Selected testers will get:
Developer Preview Guide
Individual NEES API access
Testing instructions
Structured feedback form
If you’re building an AI agent, assistant, SaaS product, or multi-user AI app and want to test NEES Core Engine V2 RC1, reply here or DM me.
I’m keeping the first testing group intentionally small so the feedback can actually shape the next improvements.
It sounds like you're hitting some of the common roadblocks that come with integrating LLM APIs into production environments. I’ve faced similar challenges while building my projects, mainly around ensuring consistency and reliability in AI outputs.
One approach that worked for me was setting up a comprehensive logging system that captures inputs and outputs every time an API call is made. This has allowed me to trace back through interactions whenever unexpected behavior occurs, providing clarity on what might have gone wrong. It also helps in creating a feedback loop where I can tweak inputs based on output patterns that arise.
I found it beneficial to create a set of benchmarks and tests for the LLM outputs, mimicking real-world usage scenarios. By generating a range of test cases, I was able to standardize the expected behavior, which provided a clearer picture of performance and edge cases. It can be tedious, but it really pays off in stabilizing your production behavior.
Lastly, consider gradually rolling out updates or changes to the way you interact with the API. This small-steps approach can help you isolate issues more effectively.
Navigating the quirks of AI APIs is certainly a challenge, but with careful tracking and consistent testing, you can mitigate many of those messier production issues. Best of luck with your governance runtime project!
Thanks Brenda — completely agree that logging, benchmarks, and gradual rollout are important parts of making LLM systems production-ready.
One of the reasons I started building NEES was that I kept seeing those practices solve the observation and testing side of the problem, while leaving the actual runtime behavior largely dependent on application-specific code.
The layer I’m exploring with NEES is slightly different:
Instead of only recording what happened after an LLM call, NEES sits in the execution path and can apply governance before, during, and around model execution — things like identity/session boundaries, policy enforcement, provider execution rules, context limits, cost controls, and trace metadata.
So ideally the stack becomes something like:
Benchmarks + tests → validate expected behavior
Logging/observability → explain what happened
NEES governance runtime → control what is allowed to happen at execution time
The Developer Preview is basically an attempt to see whether that additional runtime layer is genuinely useful once developers integrate it into real products.
Appreciate you sharing your experience — this is exactly the kind of production perspective I’m hoping to learn from.
That distinction makes sense observability explains failures, while NEES aims to prevent disallowed behavior during execution. I’d be interested to see how much application code developers need to change when integrating it. Are you aiming for a lightweight API wrapper, or does NEES require deeper architectural changes?
The list of pain points here is accurate, but the one I'd lead with is "no clear trace of why a response happened" — that's the thing that actually blocks teams from shipping LLM features to real users. Curious how NEES handles the cost side you mention: is that enforced as hard budget limits per session, or just observability after the fact? Also worth knowing for the RC1 group whether the runtime sits in-process or as a proxy hop, since latency added between app and model is usually the first objection I hear.
That’s a fair read, and I agree that “no clear trace of why a response happened” is probably the strongest production pain point to lead with.
In NEES Core Engine V2, traceability is treated as a first-class governance output rather than just logging. The runtime can carry session/identity scope, policy decisions, memory/context boundaries, execution metadata, and the governance path that led to a response, so teams can inspect not only what happened but why it was allowed, routed, escalated, or refused.
On cost: RC1 includes governed cost controls and observability, with the architecture designed to support enforceable limits rather than post-hoc reporting only. We’re intentionally exposing the current RC1 behavior to developers so they can test where hard limits, routing, caching, and context-budget decisions are actually useful in real workflows.
On deployment: the current Developer Preview is exposed as a runtime/API layer between the application and model provider, so yes, latency is something we’re actively measuring. One of the things we want RC1 testers to evaluate is whether the governance and trace value justifies the additional hop, and where the architecture needs optimization.
If you’d like to test this directly, I’d be happy to add you to the NEES Core Engine V2 Developer Preview RC1 group.
Email us at info@nees.cloud and we’ll send the setup details and individual API access.
This is interesting because the testing request is exactly where governance tends to become real.
When you say you want developers to push NEES into edge cases, are you mainly looking for integration failures — or would you also want independent testing of whether the governance rules actually produce the intended behaviour under live scenarios?
I run OpsWatch, which looks at the second problem: whether controls, escalation and decision paths behave correctly in practice rather than simply being configured correctly.
If that kind of external test would be useful for the RC1 group, I’d be interested in comparing notes.
Yes — both are useful, but the second category is especially interesting for RC1.
Integration failures tell us whether developers can successfully put NEES into a real workflow. What I also want to learn is whether the governance decisions themselves hold up under live, adversarial, or ambiguous scenarios — whether policy boundaries, escalation paths, context/memory scope, and trace decisions actually produce the intended behaviour rather than simply appearing correctly configured.
That kind of independent validation would be valuable because it tests NEES from outside the assumptions we used while building it.
OpsWatch sounds quite aligned with that question. I’d be interested in comparing approaches and possibly defining a small RC1 scenario where NEES governs the workflow and the resulting behaviour is independently evaluated against an expected decision path.
For more details about the Developer Preview and API access, feel free to email us at info@nees.cloud. We can provide the required setup information and individual API access needed to integrate NEES Core Engine V2 and test its governance functions.
Happy to compare notes.
Anna — this is exactly the kind of boundary I had in mind.
I’d be very interested in defining a small RC1 scenario where NEES governs the workflow and OpsWatch independently evaluates the resulting behaviour against an expected decision path — particularly policy boundaries, escalation, context/memory scope and trace evidence.
That would let us test not just whether NEES is configured correctly, but whether the governance layer actually holds up under ambiguous or adversarial conditions.
I’ll email you at info@nees.cloud so we can compare approaches and define a tightly scoped scenario.
Since your actual ask is recruiting testers, the thing standing in your way is the positioning, and it's fixable. "Governance runtime" plus seven problems plus six capabilities is a feature wall, a developer skimming can't tell in five seconds whether this solves a problem they have. Abstract infra categories die on that five-second test, they scroll past not because it's not useful but because they can't locate themselves in it.
The fix is to lead with the one nightmare, not the platform. Of everything you listed, "identity or memory leakage between users/sessions" is the one that makes a multi-user AI builder's stomach drop, specific, scary, instantly recognizable ("wait, does my app do that?"). Governance, traceability, policy enforcement are things people know they should care about; cross-user memory leakage is something they're afraid is already happening.
Lead with that one. "Stop your AI from leaking one user's context into another's session" gets a reply. "A governance runtime for policy enforcement and traceability" gets a nod and a scroll. Same product, one lands.
Which of your seven problems do testers bring up first, unprompted? That's the one to headline.
That’s a very fair critique, and I think you’re right about the five-second test.
We’ve been explaining NEES from the architecture outward — governance runtime, policy, traceability, memory boundaries, cost control — when a developer usually experiences the problem in the opposite direction: one concrete failure first, then the need for infrastructure.
Cross-user context or memory leakage is definitely one of the strongest examples because the risk is immediate and easy to understand.
For the current Developer Preview, though, I’m deliberately trying not to decide the headline purely from my own assumptions. One of the things I want from external testing is exactly what you pointed out: which problem developers identify first without being prompted, and which capability actually creates enough value to justify adding another runtime dependency.
So I’m going to treat this as part of the validation itself.
If testers consistently say, “I need this because I’m worried about session/memory isolation,” then that probably should become the lead message and “governance runtime” becomes the explanation underneath it, not the headline.
Appreciate this — it’s useful feedback not just on the post, but on how we should position NEES after the first RC1 testing cycle.
Smart to let testers reveal the headline instead of guessing it. One trap to build into that plan, though, or the validation will quietly mislead you: who you recruit determines which problem surfaces first, so the "unprompted #1" is an artifact of your sample, not a fact about the market.
If you recruit "developers building AI products" broadly, the most-named problem will be the most common one, probably cost or inconsistent behavior, because most builders feel those. Memory leakage between users only dominates if the people in the room actually run multi-user apps. Recruit a general pool and the nightmare wedge gets outvoted by mundane pain, and you'll conclude it's not the headline when really you just asked the wrong room.
Two ways out. Either recruit specifically for the segment the wedge implies, multi-tenant or multi-user AI builders, and see whether leakage dominates there (a wedge only has to win its own segment, not everyone). Or recruit broad but tag every response by app architecture, so you can read the single-user and multi-user answers separately. Same data, but now the signal isn't drowned by who happened to show up.
The question isn't just "what do testers name first," it's "what do multi-user builders name first," and those are different studies.
When you screen testers, are you filtering for app type, or taking whoever's game? That choice decides what your validation can even see.
That’s a really useful distinction — and you’re right that “what testers mention first” is meaningless without knowing which architecture they’re building for.
For this first RC1 cycle, I’m not hard-filtering everyone into a single narrow segment. I want some breadth because NEES touches several runtime problems. But I also don’t want to aggregate all feedback into one bucket and call the most common answer “the market.”
So I’ve started capturing the tester’s application/workflow type and where they think NEES fits in their architecture. That should let me separate signals from, for example, single-user assistants, multi-user applications, agent workflows, and systems where identity/session boundaries actually matter.
Your point also suggests a second step I hadn’t framed clearly enough: after the broad RC1 signal, I should run a more focused cohort specifically with multi-user / multi-tenant AI builders and test the memory/session isolation wedge on its own merits.
That way the question becomes less:
“Which NEES problem wins overall?”
and more:
“Which problem is strong enough to be the wedge for a specific developer segment?”
That feels like a much better validation model.
Appreciate you pushing on this — this is exactly the kind of feedback that improves not just the positioning, but the experiment behind it.
The strongest part is treating governance as a runtime layer rather than rebuilding controls inside every AI application. The real test now is whether developers can integrate it without adding enough complexity to outweigh the security and traceability benefits.
Exactly — that’s the key question we want the Developer Preview to answer.
The value of a governance layer only holds if the integration stays simple enough that developers gain more control, traceability, and safety without introducing too much friction.
That’s why the current RC1 phase is focused less on adding features and more on real developer testing: how quickly someone can integrate it, where the friction appears, and whether the benefits are clear in an actual workflow.
If the governance overhead becomes heavier than the problem it solves, that’s a signal we need to improve the developer experience.
Really appreciate you calling this out — it’s one of the most important things we’re trying to validate now.
That pattern is interesting. I’d be happy to continue the conversation outside the thread — would you be open to sharing the best email to reach you on?
Email us at info@nees.cloud for more details and conversation. Also get details of NEES Core Engine V2 developer_preview
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.