There is something interesting happening in the AI agent space.
We have spent the last couple of years building agents using prompts, tools, function calling, workflows, graphs, memory systems, orchestration layers, and increasingly complicated frameworks.
And now NVIDIA Labs has released something that made me stop and think:
What if an AI agent was just a Python object?
That is the basic idea behind NOOA — NVIDIA Object-Oriented Agents.
It is an open-source, model-agnostic Python framework that represents an agent as a Python class, where the object's fields represent state, methods represent capabilities, docstrings can define instructions, and type annotations define interfaces.
The project is still very new and explicitly described as research software. But I think the idea behind it is worth paying attention to.
So, what is actually different?
Let's look at the traditional way we might build an agent.
We could have:
- A system prompt
- A collection of tools
- Tool schemas
- A memory component
- An orchestration loop
- State management
- Some workflow engine
- Observability/tracing
- Retry logic
- Structured output handling
All of these pieces are useful.
But they also create a growing abstraction layer between the developer and the agent.
NOOA takes a different approach.
You define something like:
from nooa import Agent
class SupportAgent(Agent):
"""You are a customer support agent."""
order_db: OrderDB
def is_refund_eligible(self, order: Order) -> bool:
return (
order.delivered
and order.days_since_delivery <= 30
)
async def triage(
self,
message: str,
order: Order
) -> Ticket:
"""Create a typed support ticket."""
...
And suddenly the architecture feels very familiar.
The agent is an object.
Its state is on the object.
Its capabilities are methods.
Its interfaces are typed.
Its instructions can live with the methods.
And the interesting part is the ....
A method with a real Python implementation behaves like normal deterministic Python.
A method with an ... body becomes an LLM-driven method at runtime.
That is a surprisingly simple idea.
Why does this matter?
The thing that caught my attention isn't just the syntax.
It is the mental model.
We have traditionally thought about an AI agent as:
Prompt + Model + Tools + Memory + Loop
NOOA is suggesting another abstraction:
Agent = Software Object + Model
That is a meaningful shift.
If the agent is a Python object, then many things software engineers already know how to do become natural again.
Testing.
Refactoring.
Version control.
Tracing.
Dependency injection.
Type checking.
Composition.
State management.
Code review.
Instead of learning another workflow DSL or another orchestration abstraction, developers can start with something they already understand: Python.
NVIDIA's implementation goes further than simply wrapping an LLM in a class. The framework supports typed I/O, live Python objects passed by reference, model-generated Python as an action mechanism, programmable agent loops, context/event APIs, tracing, and long-term memory.
The part I find especially interesting: code as action
This is probably one of the most interesting pieces of NOOA.
Instead of every capability necessarily becoming a traditional function/tool schema that gets serialized into the model context, the model can generate Python and operate within the agent's environment.
In other words:
The model doesn't only call tools.
The model can write code to use the agent's capabilities.
That changes the interface between the LLM and the application.
Python methods and type annotations can become the interface the model works with.
For developers, this could eventually mean less time maintaining huge collections of tool definitions and more time defining clean software interfaces.
Of course, this also creates a very important security problem.
If an LLM can generate and execute Python, we should treat that code as untrusted.
NOOA's own documentation is very clear about this: its AST validation and module restrictions are defense-in-depth mechanisms, not a security boundary. The recommended containment boundary is OS-level sandboxing such as containers or NVIDIA OpenShell.
And I think that distinction is extremely important.
Another interesting idea: agent state
There is another architectural question that NOOA makes interesting.
Where should an agent's state live?
Today, a lot of agent state effectively lives inside the context window.
The longer the conversation becomes, the more we start thinking about:
- summarization
- context compression
- retrieval
- memory
- token optimization
NOOA instead treats the agent as an object with state.
That opens the door to a different model:
Agent
├── State
├── Capabilities
├── Memory
├── Methods
├── Context
└── Model
The LLM becomes part of the object rather than the object being constructed around an LLM conversation.
That is subtle, but I think it could become important as agents become more persistent and autonomous.
Is NOOA going to replace other agent frameworks?
I don't think we know that yet.
And I would actually argue that this is the wrong question.
NOOA is currently a 0.x research preview, and NVIDIA says its public API is not yet stable and can change between releases.
So I wouldn't recommend looking at it today and saying:
"This is the new standard for AI agents."
It isn't.
But I would definitely recommend watching it.
Because research projects like this sometimes introduce an abstraction that looks unusual initially and becomes obvious later.
Remember how strange some ideas looked before they became standard programming patterns?
The interesting question here is whether object-oriented programming becomes a useful abstraction for agent engineering.
My prediction
I don't think the future will be one giant agent framework.
I think we are going to see a convergence of several ideas.
Agents will increasingly look like software components rather than chatbot conversations.
They will have:
- Persistent state
- Typed interfaces
- Memory
- Capabilities
- Deterministic code
- Model-driven reasoning
- Observability
- Sandboxed execution
- Testable behavior
- Composable sub-agents
And the boundary between "AI logic" and "software logic" will become much thinner.
That's what makes NOOA interesting to me.
It isn't necessarily introducing another way to call an LLM.
It is asking a more fundamental question:
What should an AI agent look like from a software engineer's perspective?
And the answer from NVIDIA Labs is:
Maybe it should just look like a Python object.
What I want to see next
This is where things get really interesting.
I'd love to see how this approach evolves around:
1. Production reliability
How do these agents behave under real workloads, failures, retries, concurrency, and partial state?
2. Security
If agents can generate and execute code, sandboxing will become a fundamental part of the architecture, not an optional feature.
3. Multi-agent systems
What happens when Python objects representing agents start collaborating with each other?
ResearchAgent
↓
PlanningAgent
↓
CodingAgent
↓
ReviewAgent
↓
DeploymentAgent
Can these simply become composable software objects?
4. Agent testing
This could be particularly powerful.
Imagine being able to test an agent almost like any other Python component:
def test_refund_policy():
agent = SupportAgent(...)
assert agent.is_refund_eligible(order) is True
And then separately evaluate the probabilistic behavior of its LLM-driven methods.
That separation between deterministic logic and model-driven behavior could become a very useful engineering pattern.
5. Agent observability
NOOA already traces LLM calls, code execution, and method invocations.
I think this will become critical.
As agents become more autonomous, "the model said something weird" won't be enough for debugging.
We will need to know:
What did the agent know?
What state did it have?
What method did it invoke?
What code did it generate?
What did that code change?
What model decision happened?
What happened next?
That is software observability applied to probabilistic systems.
The bigger shift
Maybe the most interesting thing about NOOA isn't NOOA itself.
Maybe it is the direction it represents.
The first generation of AI applications taught us how to integrate models into software.
The next generation is teaching us how to make models behave like software components.
And eventually, I think we will stop drawing such a sharp line between the two.
An agent won't just be:
"an LLM with some tools."
It may become:
"a software component whose reasoning happens to be powered by a model."
NOOA is still early.
The APIs will change.
The patterns will evolve.
There will be competing approaches.
Some ideas will work. Some won't.
But that's exactly why I think it is worth experimenting with now.
Not because NOOA is already the answer.
But because it might be pointing toward a different question.
What does software engineering look like when the software itself can reason?
That is the part I'm watching.
And I have a feeling we are going to see some very interesting updates in this space over the next year.
If you're building AI agents today, I'm curious:
Would you rather build your next agent as a workflow/graph — or as a Python object?
I'd love to hear what other engineers think.
Top comments (0)