DEV Community: Anna Jambhulkar

I Built an AI Governance Runtime Layer for Production AI Apps

Anna Jambhulkar — Sat, 09 May 2026 08:11:36 +0000

Most AI apps today follow a very simple pattern:

User → App → LLM → Response

That pattern works well for demos.

It works for prototypes.
It works for simple assistants.
It works when the workflow is clean and the risk is low.

But once AI starts moving into real products, the problem changes.

The question is no longer only:

Can the model generate a good answer?

The real production questions become:

What was the AI allowed to do?
What context did it use?
What memory was active?
Which policy applied?
Why did it respond this way?
Can this interaction be reviewed later?

That is the problem I am trying to solve with NEES Core Engine.

What is NEES Core Engine?

NEES Core Engine is a governed AI runtime layer for production AI applications.

It sits between your application and the model provider.

User
  ↓
Application
  ↓
NEES Core Engine
  ↓
Governance Runtime
  ↓
Model Provider
  ↓
Governed Response

The goal is not to build another chatbot.

The goal is to give AI applications a runtime control layer for:

policy awareness
identity consistency
memory boundaries
runtime modes
traceability
explainability metadata
safer production behavior

In simple terms:

NEES helps AI apps become more controlled, traceable, and reviewable before the response reaches the user.

Why prompts are not enough

A prompt can guide behavior.

But a prompt is not governance.

A prompt cannot reliably answer:

Which policy was active?
What memory scope was allowed?
What should happen if two instructions conflict?
When should the AI escalate?
What response path was used?
How do we debug this response later?

Most production AI problems do not happen because the model is completely useless.

They happen because the system around the model is weak.

The workflow is unclear.
The context is messy.
The memory boundary is undefined.
The role is inconsistent.
The decision path is not visible.

So the model is forced to guess.

That is where governance becomes necessary.

What NEES adds to the AI stack

A direct model call usually gives you:

Prompt → Model → Text Response

A governed NEES call gives you:

Request
  ↓
Runtime governance
  ↓
Model response
  ↓
Governance metadata
  ↓
Traceable output

That means the response is not only text.

It can also carry metadata such as:

{
  "reply": "Governed assistant response...",
  "trace_id": "trace_xxxxx",
  "engine_source": "core_engine",
  "governance": {
    "status": "allowed",
    "mode_used": "supportive",
    "policy_applied": true,
    "memory_scope": "session"
  }
}

The exact response fields may evolve during the developer preview, but the principle is the same:

Every AI response should be easier to understand, debug, and review.

A simple example

Here is a basic Python request:

import requests

response = requests.post(
    "https://api.nees.cloud/chat",
    headers={
        "Authorization": "Bearer YOUR_NEES_API_KEY"
    },
    json={
        "message": "Explain why AI apps need runtime governance in simple terms.",
        "mode": "supportive",
        "session_id": "demo-session"
    },
    timeout=45
)

print(response.json())

This is still a simple API call.

But instead of treating the model response as a black box, NEES routes the request through a governed runtime layer.

Why traceability matters

When an AI response goes wrong in production, teams need more than:

“The model said this.”

They need to know:

what request came in
what mode was active
what policy applied
what memory scope was used
what provider/model path handled the request
whether the response was allowed, modified, or blocked
how the interaction can be reviewed later

That is why trace IDs matter.

A trace ID acts like a reference point for debugging and review.

Without traceability, AI debugging becomes guesswork.

Memory boundaries matter too

Memory is powerful.

But uncontrolled memory can create serious problems.

If every past interaction can influence every future response, the system becomes harder to reason about.

So memory should not be treated as unlimited context.

It should be governed.

A production AI system should be able to reason about:

what belongs only to the current session
what can be reused across sessions
what requires explicit consent
what should never influence a response
when memory usage should be visible or traceable

The goal is not simply:

Give the AI more memory.

The goal is:

Control when memory is used, why it is used, and how that usage can be reviewed.

Runtime governance vs another AI agent

I do not think the answer to every AI problem is “add another agent.”

Sometimes the missing layer is not another AI.

Sometimes the missing layer is control.

AI agents become useful when the system around them is designed properly:

clear workflow boundaries
role permissions
escalation rules
memory scope
policy checks
observability
fallback behavior
human review when needed

NEES is focused on that runtime layer.

It is not trying to replace the model.

It is trying to make AI behavior easier to govern before it reaches users.

Where this can be useful

NEES Core Engine can be useful for teams building:

AI assistants
AI agents
customer support bots
education apps
workflow automation
internal company copilots
AI content pipelines
production AI tools that need auditability

The common thread is simple:

If AI behavior affects real users, real workflows, or real decisions, it should be controlled and traceable.

Developer preview is now open

I recently opened a public developer preview repo for NEES Core Engine.

The repo includes:

Python quickstart
Node.js quickstart
cURL and PowerShell examples
API reference
governance flow documentation
15-minute integration guide
API key request template
developer feedback template

Developer preview repo:

https://github.com/NEES-Anna/nees-core-developer-preview

There is also a live sample app connected to the governed runtime:

https://naina.nees.cloud

The sample app is useful for seeing the governed response flow in a real interface.

What I am looking for

This is still early.

I am not looking for generic traffic.

I am looking for honest feedback from developers, AI builders, founders, and teams working with production AI systems.

I would especially like feedback on:

Is the API approach clear?
Does the governance metadata feel useful?
Would trace IDs help you debug AI behavior?
How would you expect memory boundaries to work?
Would this fit better as a hosted API, SDK, or both?
What would you need before using this in a real product?
What integration docs should come next?

The first goal is not to make the system complex.

The first goal is to make the first 15 minutes useful.

A developer should be able to send one governed request and immediately understand:

This is different from a direct model call because I can see how the response was governed.

Final thought

AI is moving from demos into production.

That shift changes the infrastructure requirement.

In demos, a good answer is enough.

In production, teams need control.

They need to know what the AI was allowed to do, what context it used, what policy applied, and how the decision can be reviewed later.

That is the layer I am building with NEES Core Engine.

Not another chatbot.

A governance runtime for production AI.

Why I’m building a Windows-first emotional AI assistant (lessons so far)

Anna Jambhulkar — Mon, 22 Dec 2025 13:21:10 +0000

Most AI products today are optimized for speed, accuracy, and scale.

And that makes sense.

But while using AI tools daily, I kept running into the same feeling:
every interaction felt stateless. Every session started from zero.
No memory. No continuity. No sense of knowing the user.

That’s where my curiosity started.

The problem I noticed

Modern AI assistants are impressive, but they behave like strangers who forget you every day.

You explain your preferences again.
You restate context again.
You rebuild workflows again.

From a technical perspective, this is fine.
From a human perspective, it feels broken.

Humans don’t work in isolated prompts — we work in continuity.

Why Windows-first (and not cloud-first)

One decision I made early was to build this as a Windows-first assistant, not a browser tab or a purely cloud-based tool.

Why?

Because a personal computer is still the most intimate computing device we own:

It holds our files

It reflects our workflows

It stays with us for years

Building locally (or at least desktop-native) allows:

Better context awareness

Stronger privacy boundaries

Tighter integration with daily work

Instead of AI being “somewhere on the internet”, it becomes present.

Emotional AI ≠ pretending to be human

A common misconception:
emotional AI means making the assistant sound emotional.

That’s not what I’m exploring.

For me, emotional AI is about:

Remembering preferences

Maintaining interaction history

Adapting tone and behavior over time

It’s not about fake empathy.
It’s about continuity.

What I’ve learned so far (the hard parts)

Memory is expensive — technically and ethically

Storing memory isn’t just a database problem.
You need to decide:

What’s worth remembering?

What should be forgotten?

Who controls that memory?

“Personal” quickly becomes “creepy” if done wrong

There’s a very thin line between helpful continuity and overreach.
Designing that boundary is more important than model choice.

Developers underestimate emotion in tools

Many devs (myself included) initially think users only care about features.
In reality, how a tool makes you feel over time strongly affects retention.

Why I’m sharing this early
This project is still in a tech-trial stage.
I’m intentionally sharing before everything is “perfect”.

Because the most valuable insights so far haven’t come from metrics —
they’ve come from conversations.

A question for builders here

When you think about the tools you use daily:

Do you value memory and continuity?

Or do you prefer tools to stay stateless and predictable?

*Where do you personally draw the line?
*
I’d love to learn from real experiences, not just theory.

Thanks for reading 🙏