LOG 010: Building Nine — A Headless AI Agent Operating Layer for Paragon9
In this series:
LOG 010.1: Architecting a Headless AI Bridge — Standardizing OpenClaw under Systemd
LOG 010.2: Connecting OpenClaw to Microsoft Teams on a Headless Linux Server
LOG 010.3: Setting Up a Dedicated M365 Identity for Nine
LOG 010.4: Building the SharePoint 9OS Command Deck and Teams Channels
LOG 010.5: Connecting OpenClaw to Microsoft Graph and Bringing Nine Online
LOG 010.6: Connecting Nine to Azure DevOps — and Getting Credential Custody Right
01. THE SYSTEMS SOURCE: THE NAME
There is a small loop built into this project that I appreciate.
The agent started as Agent9 — a working concept, a placeholder. It got shortened to 9 the way all working names do when you're moving fast. Then, for readability in Teams conversations and audit logs, it lengthened itself back out into Nine. And when the typography wants to have a little fun: N9ne.
The name settled into a small identity stack. Agent9 is the concept. 9 is the shorthand. Nine is the readable name you'll see in SharePoint logs and Teams messages. And N9ne is what shows up when Paragon9's branding and the agent's identity decide to overlap.
That loop — something that starts abstract, gets compressed, and then re-expands into a legible identity — is exactly what this series documents. Taking an AI tool and building it into an accountable operational layer with a name, a workspace, scoped permissions, a runtime, and a place it reports to.
The Insight: There is a difference between a tool you use and a system member you deploy. Nine is the latter. This series is the blueprint for that distinction.
02. THE BUILD SOURCE: THE SERIES
This is a four-part series. Each entry stands on its own, but together they trace the complete stack — from OS and infrastructure through identity, workspace, and live Graph API integration.
LOG 010.1: Architecting a Headless AI Bridge — Standardizing OpenClaw under Systemd
The foundation. This entry covers running OpenClaw as a durable, headless service on a physically minimized Ubuntu Server — not a cloud VM, not a clean install, a real machine with a stripped OS and the gaps that come with it.
What's documented: UEFI and static IP decisions, the ubuntu-server-minimal missing dependency problem (including lsof), the systemd PATH disconnect, the Crestodian TTY check and the script PTY workaround, gateway persistence via loginctl enable-linger, the XDG_RUNTIME_DIR fallback for headless environments, SSH tunnel setup for cross-device access, and agent credential isolation.
→ LOG 010.1: Architecting a Headless AI Bridge — Standardizing OpenClaw under Systemd
LOG 010.2: Connecting OpenClaw to Microsoft Teams on a Headless Linux Server
The bot layer. Teams connectivity has two independent data paths: outbound authentication to Azure's Bot Framework and inbound webhook delivery from Microsoft's servers, and each requires its own solution when there's no browser and no GUI.
What's documented: Azure App Registration setup, Bot creation and Teams channel enablement, why Cloudflare Tunnel wins over devtunnel and ngrok for headless servers, openclaw.json configuration with dmPolicy and AAD Object ID requirements, manual Teams app manifest build (and why teams.cli is unreliable in restrictive org tenants), icon generation, ZIP sideload, and end-to-end verification — with eight specific gotchas at the exact step they occur.
→ LOG 010.2: Connecting OpenClaw to Microsoft Teams on a Headless Linux Server
LOG 010.3: Setting Up a Dedicated M365 Identity for Nine
The identity layer. This entry documents why Nine gets its own licensed M365 account — not a service account, not a shared mailbox, a real user with real permissions, scoped to exactly one machine via NordVPN and Conditional Access.
What's documented: NordVPN Business installation on a headless server (including the token-based auth workaround), dedicated static IP configuration, LAN SSH preservation after killswitch, M365 account creation, Entra Named Location, Conditional Access policy logic, and the Exchange transport rule that prevents Nine from sending external email without review.
→ LOG 010.3: Setting Up a Dedicated M365 Identity for Nine
LOG 010.4: Building the SharePoint 9OS Command Deck and Teams Channels
The workspace. This entry covers the naming architecture — Nine (the identity), 9OS (the infrastructure), 9Claw (the runtime) — and then builds the operating environment: five SharePoint document libraries, a private Teams team, four command channels with defined routing logic, and bot registration.
What's documented: The three-layer naming convention, SharePoint 9OS site provisioning, library structure and permissions, the Reference read-only lock, Teams team and channel creation, 9Claw bot installation, per-channel registration via @mention, and the Graph API disambiguation for duplicate group names.
→ LOG 010.4: Building the SharePoint 9OS Command Deck and Teams Channels
LOG 010.5: Connecting OpenClaw to Microsoft Graph and Bringing Nine Online
The final connection. This entry wires everything together: Entra app registration, Graph API permissions, client secret handling, the msgraph.json separation from openclaw.json (and why that matters), SharePoint access verification, Nine's SOUL.md identity file, dedicated workspace configuration, Cloudflare Tunnel for inbound Teams webhook delivery, and the live end-to-end test that confirms Nine is operational.
What's documented: App registration and permission scoping (delegated vs. application permissions), the SharePoint 401 fix, credential file isolation, full authentication and write tests, channel conversation ID mapping, SOUL.md structure and operating principles, workspace isolation from OpenClaw source code, Cloudflare Tunnel as a systemd service, the complete gotcha reference table, and the full stack verification diagram.
→ LOG 010.5: Connecting OpenClaw to Microsoft Graph and Bringing Nine Online
03. THE LEGACY SOURCE: WHAT NINE BECOMES
The point of this series is not to document a tool install.
The point is to show what it looks like to bring an AI agent online as an accountable operational layer — named identity, scoped permissions, durable runtime, structured workspace, review channels, audit trail, and logged work. Every component in this stack exists for a reason. The dedicated M365 account isn't bureaucracy; it's a control plane. The Exchange transport rule isn't restriction; it's a review gate. The SOUL.md isn't decoration; it's the operating contract that tells Nine who it is and what it is not allowed to do unilaterally.
Nine is Phase 1. The runtime will evolve — OpenClaw today, Hermes when we migrate. The infrastructure remains constant. The identity remains constant. The operating principles remain constant.
That is the architecture worth building.
The Insight: When you treat an AI agent as infrastructure — with a name, a boundary, a workspace, and an audit trail — it stops being a novelty and starts being a team member. Build the structure first. The capability follows.
[SYSTEM NOTES]
- Agent Identity: Nine (N9ne) — Paragon9's autonomous AI agent
- Runtime: OpenClaw (9Claw in Teams) — migrating to Hermes in a future series entry
- Infrastructure: 9OS — Microsoft 365, SharePoint, Teams, Exchange, Entra, Graph API
- Security Anchor: NordVPN dedicated static IP + Entra Conditional Access
- Inbound Delivery: Cloudflare Tunnel →
localhost:3978(Teams webhook) - Series Status: LOG 010.1 through 010.5 are complete. Future entries will cover Hermes migration, Signal/Telegram channels, and per-principal scoped agent identities.
Stay Resilient.
— Greg Scott Kirk (Tek)
This is the architecture Paragon9 installs for mid-market firms — modernized, documented, and built to run without its operator. If you want it running in your business, the conversation is free.