Building Enterprise Agentic Platforms: Lessons from NOVA

What is an enterprise agentic platform?

It is not a chatbot with plug-ins. It is a layered system that turns an intent into a plan, runs versioned skills through specialist agents and delivers a reviewable result. NOVA is my attempt at it, rolled out to 800 employees at Devoteam.

I use three questions to test any platform that claims to be agentic. Who is responsible for context? Who decides what an agent may do on its own? Who proves that a new version is better than the previous one? If the answers are the prompt, the model and the demo, it is an assistant with ambitions, not a platform. The rest of this article follows these three questions, which map to the bricks act, know and learn.

Why one orchestrator instead of a menu of agents?

NOVA is organised in layers. A single orchestrator frames the request, plans, delegates to specialists, supervises the work and assembles the result. Behind it, specialist agents for product, project, design and engineering each master a domain and carry their own versioned skills. A research agent brings context, and a validation agent checks each deliverable before it reaches the user.

The user never chooses an agent. It sounds like a UX detail, but it is the main adoption decision: people do not want to learn an org chart of bots. They want to state what they are trying to achieve and receive work they can edit.

The output matters as much as the routing. The public NOVA repository describes deliverables as structured, versioned and editable artifacts with citations, not as chat messages someone must copy somewhere else. That is what makes the result reviewable by a human, and review is where trust is built.

Why is context a product and not a prompt?

Most failures I saw were not model failures. Agents cited a decision that had been replaced, mixed two versions of a specification, ignored a constraint or, worse, exposed a document to someone who should never have seen it. A better model does not fix any of these.

So NOVA retrieves its context through ORBIT, as the user, with their permissions, and an answer can say why a source was included or excluded. Treating context as a governed layer made the platform easier to trust and to audit. According to the public README, ORBIT works on these points:

The practical consequence is a different way of debugging. When an answer is wrong, I no longer start by rewriting the prompt. I look at which sources were retrieved, which were excluded and why. More often than not, the fix is a stale document, a missing permission or an unresolved contradiction between two sources, and none of those are visible from the prompt.

• Ingestion of team sources with detection and redaction of personal data.
• A living memory of decisions, constraints and risks, with a lifecycle (proposed, validated, replaced, obsolete, forgotten) and provenance.
• Permissions and data classification applied before anything reaches an agent.
• An explainable reason code for each item kept in or left out of a context.
• Connectors to the tools teams already use, including MCP connectors.

How do NOVA, ORBIT and FORGE divide the work?

I kept the three responsibilities apart on purpose, because mixing them is how platforms become impossible to reason about. NOVA never duplicates ORBIT or FORGE: it asks ORBIT for context and is evaluated by FORGE through an adapter.

Why evaluate before scaling?

A platform used by hundreds of people cannot rely on someone’s impression that it seems better. Each release is benchmarked and regression-tested with FORGE before it reaches more users. The FORGE README describes scenarios, deterministic rules, LLM judges, human review and baseline versus candidate experiments, with scores that always trace back to a criterion and a step of the execution.

I would rather say this plainly: a score without an explanation is a rumour. If an evaluation cannot show which criterion and which step produced a number, nobody can act on it.

I also learned to keep the evaluation set honest. The FORGE README describes public, private and fresh scenarios, so that a team cannot quietly optimise for the tests it can see. That is the part of evaluation most teams skip, and it is the part that protects you from a flattering benchmark.

Who actually learns in a platform that learns?

“FORGE learns” is a shorthand, and it can mislead. Nobody trains model weights in this setup. FORGE produces evidence. NOVA distils that evidence into short lessons, which are versioned instructions, and deploys them through a proof gate, a canary and an approval, with the option to roll back. ORBIT keeps the governed learnings that NOVA later retrieves as context.

This separation matters for a large company. Instructions can be reviewed, diffed and reverted. Weights cannot, at least not by the people who own the business process.

How do you keep autonomy under control?

Autonomy is a dial, not a switch. The NOVA engineering capability, which specifies, codes, tests and opens pull requests, offers a guided mode where a human validates the plan and the merge, and an autopilot mode that goes further on its own. The controls I consider non-negotiable are these:

• Human approval gates at the steps that touch external systems.
• Recorded provenance, so a user can ask why an element was included.
• An autonomy policy and a tool registry, so agents only use what they are allowed to use.
• Proposed versions instead of silent updates when a cited source changes.
• Replay of a finished run without writing to external systems, to compare cost, time and context.

What did I measure and see?

I need to be careful here. NOVA, ORBIT and FORGE are public betas, and I describe their design, not a production guarantee. The figures I can stand behind come from the platform work around them.

At Devoteam, NOVA reached 800 employees through a cross-functional team of 15 people, inside a group of 10,000+ consultants in 25 countries. On the DILA public-sector platform, the same discipline of shared components and evaluation produced the results below.