How Agenoia is built — and why

Not a list of buzzwords. A set of deliberate choices, each one made because of something we learned the hard way — or already knew before we started.

Most "AI agent" pitches lead with a demo. We'd rather lead with the reasoning behind the demo, because the reasoning is what determines whether something still works once real people, real money, and real deadlines are involved. This page walks through the main architectural decisions behind Agenoia, in plain language, and links out to the deeper, more technical version of each one.

Why we think we're the right team to build this

A lot of teams could write the code. Very few start with all of the following already in place:

• We already built the system of record. ]project-open[ has been used by project-based businesses for two decades. We're not guessing at how project management actually works inside a real company — we wrote the software it already runs on.
• We've sat in the project manager's chair. Years of hands-on consulting means we know where the real bottlenecks are, not the ones that look good in a slide deck.
• We've formalized what "self-aware" actually means for a piece of software. Most agent products use the word loosely. Ours comes out of ongoing research into how to define and measure it — see functional-consciousness.com.
• We've built and run a software company before. Shipping a good demo and shipping something a business can depend on for years are very different problems. We've done the second one already.
• We already have customers to build for. ]project-open['s existing user base is a warm starting point, not a cold market we have to discover from scratch.
• We're building in the open, on purpose. Agenoia's foundations are open-source (more below), which matters to exactly the kind of organization that's cautious about locking itself into a black box.
• We're not starting from a whiteboard. A working prototype is already in the hands of early design partners — see the last section on this page.

Each of these alone is common. Together, in one team, they're rare — and each one shows up directly in a design decision below.

We studied failure before we studied features

Before writing a line of Agenoia's planning logic, we did a deep pass on why enterprise AI agents disappoint in practice — not in benchmarks, in actual production use. The short version: it's rarely a raw capability problem. It's that the agent has no way to represent what it knows about itself — how confident it is, whether something it's relying on is still current, how much authority it actually has in this situation. See Why enterprise agents still fail for the full argument. Everything that follows on this page is a direct response to that analysis, not a feature list assembled independently of it.

A small, open foundation — chosen on purpose

Agenoia is built on Nanobot, a small, open-source agent runtime, rather than a large closed platform. That was a deliberate trade: an open foundation means we can add exactly the pieces a real ERP integration needs, instead of working around the limits of someone else's black box.

A concrete example: connecting an agent to ]po[ properly requires passing permission information through every step of a conversation, not just at login. Because Nanobot is open, we could add a communication channel that carries this permission context end-to-end — something we simply couldn't have done on a closed platform. The self-modeling capabilities described on the self-modeling page are the next, larger example of the same pattern: real additions to an open core, not a request filed with a vendor. More on this choice on the forthcoming open-source foundations page.

Permissions and safety came first, not last

We didn't bolt security on after the prototype worked. It was one of the first design decisions, and it shapes everything else:

• Agenoia never touches a client's core business data directly. Every read and write goes through ]po['s own REST interface, which already knows who is allowed to see and change what.
• Agenoia keeps its own working memory — the self-models described on the self-modeling page — in storage that is separate from the client's core system, so an AI-generated hunch is never confused with a fact in the system of record.
• Agenoia never takes action on its own. Every proposed action is submitted as a proposal into ]po['s own, existing workflow engine, where a human reviews and approves it exactly the way they'd review a colleague's request today.

The practical effect: even if Agenoia gets something wrong, it can't silently do anything about it. A person is always the last step before anything real happens. The full technical picture will live on a dedicated permissions and safety page.

Designed to scale from day one

Agenoia's self-models — the structured information it keeps about goals, confidence, trust, and progress — are stored in a graph database, so the agent can reason about how different pieces of knowledge relate to each other, not just retrieve them one at a time. We designed this layer to hold millions of entries without slowing down, because a system that works in a demo and falls over in production isn't actually working. More detail will live on a dedicated performance at scale page.

Built on ]po[ first — built to go anywhere

]project-open[ is our first, deepest integration, and it gives Agenoia a real head start: two decades of project-management data structures already exist there, ready to use. But every design decision has been made so that Agenoia is not permanently married to ]po[. The connection to any given ERP system — including ]po[ — is kept in its own separate, self-contained store, so the same core agent can eventually plug into a different system's data model without a rebuild. Starting with ]po[ is a head start, not a ceiling. More detail will live on a dedicated ERP integrations page.

Already in real hands

Agenoia isn't a concept on a roadmap. A working prototype is already deployed with early design partners in project-based service businesses, handling real day-to-day work under real supervision. That's given us production feedback no amount of internal testing could — see the roadmap for what that's already changed and what's coming next.

For the reasoning behind how we decide what an agent needs to know to answer a given question at all, see methodology. For the specific self-models Agenoia carries today, see self-modeling.