The first public SDK for NEES is intentionally smaller than the engine behind it

A few weeks ago I was posting here about agent governance mostly as an architecture problem.

• Where should authority live?

• When should an agent be forced to clarify instead of acting?

• What happens when policy or context changes after a decision has already been made?

• How do you prove what was actually authorized later?

Those discussions helped a lot.

But at some point you have to stop explaining the architecture and let people actually interact with the product.

So this week I published the first NEES Python SDK developer preview.

The interesting part is that the SDK is deliberately much smaller than NEES Core itself.

Today, SDK v0.1.1 exposes one supported capability:

chat:invoke

A Python application can install the client:

• bash id="j3opd4"
  pip install nees-core-sdk

and call NEES like this:

• python id="mkso3j"
  from nees import NEESClient

client = NEESClient()

result = client.chat(
"Explain runtime governance in simple terms."
)

print(result.reply)
print(result.governance.decision)
print(result.governance.status)
print(result.governance.reason)

---

That is intentionally the public SDK surface right now.

You get authenticated invocation, request/session correlation, an optional trace ID, and a limited public governance result.

You do not get the internals.

And you do not get the entire Core exposed as a giant API surface on day one.

That part is deliberate.

NEES Core itself is already much broader than this first SDK release.

The runtime currently includes supported mechanisms around authority and delegation, resource/operation scope, human approval and resume, state-aware requalification, execution qualification, decision/evidence lineage, sequence limits, cost governance, containment, enterprise governance, and bounded governed action execution.

But not every internal capability should immediately become a public SDK method.

I would rather stabilize the integration boundary one layer at a time than dump the engine into a client library and call it a developer platform.

There is another part of the release that is probably more useful if you want to understand what NEES is actually doing beyond the current SDK.

We also have a public Governance Lab.

The SDK shows the integration surface.

The Governance Lab shows more of the governance behavior.

It lets visitors interact with selected NEES-powered flows and inspect normalized governance and evidence results without exposing the Core implementation itself.

That includes reasoning-only interactions as well as a bounded governed reference-action path.

So instead of only reading that NEES can make governance decisions, you can actually see outcomes, execution state, and linked evidence through the public interface.

We have also verified that bounded reference-action path in production.

That matters to me because it moves the project beyond:

“the policy engine said ALLOW”

toward:

“this specific governed action was allowed, executed through the participating path, and has linked evidence.”

The Governance Lab is not a simulation of every Core feature, and it is not proof that NEES controls arbitrary external systems.

It is a public demonstration of selected, real governed behavior through the supported runtime boundary.

That distinction is important.

NEES is not claiming universal control over arbitrary Python code, operating-system activity, network traffic, or every external tool an agent might reach.

Execution governance is strongest where an action participates in a registered, governed path.

That is the model we are building around.

There is also a commercial side to this that I understand much better now than when I started posting about the project here.

One of the best comments I got on an earlier post was that the enforcement engine is often not the hardest part in enterprise adoption.

The harder question can be organizational:

• Who owns the policy?

• Who approves authority?

• What does the auditor or risk team actually see when something is refused at 2am?

And who is really the buyer — the developer integrating the system, or the team responsible for approving its use?

I think the answer is probably both, but they care about different things.

The developer wants a clean integration surface.

The organization wants boundaries, evidence, accountability and a defensible answer to why an agent was allowed to act.

That is also why I think both the SDK and the Governance Lab matter.

The SDK answers:

“How would I integrate this?”

The Governance Lab answers:

“What does this governance actually look like when it runs?”

The current developer preview is controlled access because I want to learn from real integrations before exposing more of the Core.

I am especially interested in developers building:

• tool-using AI agents
• workflow automation
• enterprise copilots
• assistants that can modify business data
• systems where an AI can act on behalf of a user

Developer docs and examples:
https://github.com/NEES-Anna/nees-python-sdk-developer-preview

Governance Lab:
https://nees.cloud

Request developer access:
https://nees.cloud/request-access

One thing I am particularly curious about:

If you were integrating governance into an existing agent today, what would you want exposed first after chat?

• Action submission?

• Approval/resume?

• Evidence lookup?

• Authority and scope?

• Something else?

That answer will probably matter more than my roadmap assumptions.