Office automation before AI: lessons from the NATO C3 case

When employees adapt software to their work, they are addressing a specific gap: the standard platform understands a general task, while their department has particular rules, exceptions and connections to other systems. That need predates generative AI.

In Barcelona in November 2010, a NATO C3 Agency representative described practical Microsoft EPM customizations: time entry, project summaries and a PeopleSoft connection. Today, with AI helping turn task descriptions into tools, the older case raises a current question: where does personal customization end and shared company architecture begin?

This is part three of our series. Following skills and security, we examine shared services for employee applications and AI agents. Historical and technical sources were checked on November 1, 2026. The modern architecture below is our proposal, not a description of NATO’s current systems.

Microsoft’s official page confirms Project Momentum 2010 EMEA in Barcelona on November 16–18, 2010. Its 2024 date concerns the download archive, not the event. Microsoft: Project Momentum 2010 EMEA event presentation archive ↗

A November 25, 2010 report by attendee Michel Operto describes Nick Hillman’s presentation: small time-entry customizations, automated project summaries and a bidirectional Microsoft EPM–PeopleSoft integration. It identifies him as Business Management Executive for Project Management. This is contemporary attendee testimony, not an official implementation audit. Michel Operto: a contemporary account of Nick Hillman’s NC3A presentation, November 25, 2010 ↗

NC3A means NATO Consultation, Command and Control Agency. NCI Agency’s official history lists it among the organizations merged in 2012. There is no basis for treating this as a group of generals personally writing programs. NCI Agency: institutional history and the 2012 merger ↗

The sources do not identify who coded each customization, whether they worked in IT or whether special European project logistics motivated it. They also do not establish current Claude use in the described process.

Adapting a large platform can involve small changes that make daily work easier. Integration adds separate value: employees need a coherent process, not a count of purchased products.

The historical account does not establish widespread development by ordinary end users. It does illustrate a persistent need for software to reflect specific working rules. Generative AI makes experimentation more accessible without removing that need or accountability for results.

Calling the 2010 work modern vibe coding is therefore inaccurate. The shared element is the desire to adapt tools. Development methods, specialist involvement and technical environments could be entirely different.

Today, companies should identify recurring customizations. If people repeatedly build similar exports, forms and summaries, a shared service or an accessible way to use one may be missing.

Consider a fictional company. Sales builds a catalog reconciliation tool, procurement an offer comparison and a manager a task summary. Each is useful, but each develops its own rules for prices, access and status meanings.

Eventually, two applications answer the same question differently. An old export, different formula or missing approval may explain the discrepancy. AI accelerated screens and code, while the company acquired inconsistent versions of its process.

Shared foundations are needed: who may read an object, which catalog version applies, where amounts are calculated and what approval means. These rules can be executed in business services used by different clients.

This preserves room for convenient forms, reports and agents. Critical rules need not be reinvented in every personal application. Flexible presentation can coexist with consistent evidence.

Model Context Protocol describes how AI applications interact with capabilities provided by servers, including tools, resources and prompts. It can connect an agent to permitted company functions. The protocol itself is not a complete business-management system. Model Context Protocol: official architecture ↗

An MCP adapter might expose reading an accessible order status or preparing a draft using an approved catalog. These should be bounded functions with known parameters, rather than unrestricted database access through a technical account.

MCP does not replace a data model, calculations, authorization or audit records. Those are also needed with an ordinary API or another integration approach. Protocol choice addresses client connection; authority and business meaning remain with the service.

Break “invest in MCP” into work on business operations, data, rules and then a suitable agent adapter. Sometimes an ordinary API or repairing an existing service is the most useful first result.

People need to see what they approve. Contract comparisons, proposal contents, source evidence and consequential actions benefit from a clear screen. Free-form dialogue is not always convenient for comparing versions or noticing a missing field.

An interface helps expose errors, explain restrictions and serve people who do not use an agent. It also supports administration, troubleshooting and recovery after automation failure.

Reducing duplicate forms and moving repeated logic into shared services can be sensible. MCP’s existence does not establish a universal case for sharply cutting frontend investment. Budget allocation is a task-specific decision, not a verified general forecast.

In this proposed design, an employee application and an agent are different ways to invoke one checkable operation. Natural-language requests should not weaken validation.

First define its purpose and boundaries. Reading an accessible document version, proposing a change and approving it are different actions. Separate them so reading does not quietly confer write permission.

Specify fields, allowed values, freshness requirements and possible outcomes. Detect a version mismatch when a source changes. If an operation already completed, repeating the request should not create a duplicate result.

Errors belong in the contract: access denied, insufficient data, stale version or approval required. A persuasive agent explanation should not turn one of these outcomes into permission to proceed.

Check authority for the actual employee and object. A shared key with organization-wide access creates risk even when tools are carefully described. The published MCP specification treats HTTP authorization separately, including token-recipient and access-scope requirements. It does not replace service-level business checks. MCP: HTTP authorization, specification version 2025-11-25 ↗

MCP security guidance also prohibits token passthrough: accepting tokens not issued for that MCP server and forwarding them downstream. A protocol connection should not become a route around another system’s authority controls. MCP: security best practices, version 2025-11-25 ↗

A small tool needs an owner who understands its purpose, data and correctness criteria. Routine use also requires support arrangements. An employee might own the idea and form while IT owns the environment and shared service.

Distinguish a personal experiment, departmental tool and critical corporate process. Moving between levels means reviewing data, access, checks and support. An application should not quietly become business-critical merely because sharing it is convenient.

The lifecycle includes change and retirement. Microsoft’s Power Platform ALM guidance considers development alongside governance, testing and maintenance. That is a useful organizational reference for generative-AI-built tools too. Microsoft: Application lifecycle management with Power Platform ↗

When an author takes leave or changes roles, the tool should remain understandable. Preserve its description and version, assign ownership and provide a recovery path. Possessing code without understanding the process does not solve handover.

The prototype already separates proposal, calculation, approval and local task creation. Documents have versions and passage references, and retrieval checks current permissions. These mechanisms could support bounded operations exposed through different interfaces.

For example, a human interface and future agent could use the same proposal calculation and version approval. The agent helps prepare data; the application retains rules and evidence. Such an MCP layer for employee programs is not implemented and needs separate integration.

The Analyst Council uses several roles of one configured model and a shared snapshot of accessible sources. It is not an independent expert panel. The current prototype also lacks ready email, CRM and accounting connectors.

Start with a specific business action and checkable data. A promise to connect any agent to the entire company would be too broad without specifying authority, versions and permitted consequences.

An initial pilot can prepare a result without sending it externally: a proposal draft, discrepancy list or task proposal. The function receives the necessary data and returns evidence with its output.

Test the same tasks through a form and an agent client. Assess usability and consistency of calculations, permissions and error handling. Separately test repeated requests, source-version changes and access revocation.

Then add the agreed approval step and bounded application of the result. Preserve who decided and which content the decision covered. Validating one operation does not validate every other tool.

This gives a path from employee initiative to a maintained process. NC3A’s historical case reminds us that platform adaptation is an established need. The new opportunity is shared, checkable operations for people and agents.

We can examine that transition with AI Office: choose an action, define data and rights, design its interface and evaluate agent access. The useful outcome is a process that remains understandable and manageable when applications, models or employees change.