Technical Product Case Study

Office OS: Building AI Systems That Carry Work to Completion

What shipped, where it broke, and how the lessons changed my product judgment.

I built Office OS to test whether AI could do more than generate answers. Could it carry work through communications, CRM, calendars, attribution, approvals, and recovery? The core systems are deployed, and the architecture supports multiple tenant-scoped businesses and independent worker runtimes. It is built and ready to onboard customers without rebuilding the platform for each business.

Mike Birtwistle · Kamloops, British Columbia · Open to remote roles

Customer-Ready System

The platform is built. A new customer is configuration, not a rebuild.

The system already supports tenant-scoped configuration, separate business knowledge, role-specific assignments, controlled tools, and independent worker runtimes. Each customer receives their own identity, knowledge, assignments, permissions, channels, and operating context while the same platform serves every business.

Deployed Core

Customer-facing infrastructure

Voice and SMS infrastructure, GoHighLevel operations, website and funnel, server-side attribution, database, and production deployment.

Operating in Production

Agent-operated workflows

A phone-accessible AI office manager, persistent operating context, CRM outreach synchronization, and selected research and production workflows.

Operating Library

Reusable capabilities

A 45-skill operating library, 12 composed workflows, research tools, programmatic video, approval components, health checks, and agent evaluations.

Ready to Onboard

Repeatable customer deployment

Add the customer's knowledge, assignments, tools, permissions, channels, and runtime through configuration. The platform itself does not need to be rebuilt.

My Role

AI accelerated the implementation. I remained accountable for the judgment.

I directed the product, architecture, decomposition, integration, deployment, and operating decisions. I used coding agents extensively because they let one builder test ideas at a pace that previously required a team. I did not treat generated code as delegated judgment. I decided what the system should do, where a person must stay in control, which failures mattered, and whether the result was safe enough to keep.

My operating instincts came from six years in underground mine dispatch. I monitored ventilation, gas-detection, compressed-air, crushing, conveying, and production systems while coordinating work across people, equipment, and departments. In that environment, a persuasive demonstration meant nothing if the system failed during an exception.

The Operating Problem

The hard part is not the model. It is moving work safely between systems and people.

Small businesses already have phones, calendars, customer records, websites, advertising accounts, and payment tools. The owner still has to carry context between them, notice what was missed, approve risky decisions, and recover interrupted work. Office OS was my attempt to make the worker the product rather than adding another dashboard for the owner to operate.

01

Owner

Sets direction, approves consequential actions, and handles exceptions.

02

Office manager

Receives instructions, prepares briefings, and delegates bounded work.

03

Employees and skills

Apply procedures, tools, permissions, approval rules, and evidence requirements.

04

Business systems

Carry work through CRM, phone, calendar, web, data, media, and advertising tools.

Proof 1 · Live

Keep the call alive when context retrieval stalls

The communications system resolves the business from the number called, assembles the voice agent at call time from approved configuration, injects customer and business context, exposes real calendar and CRM tools, and creates a human handoff when the agent reaches its limit.

The failure

A knowledge-base lookup sat directly in the live-call path. When it slowed down, assistant creation stalled. Calls could end before the caller heard a response.

The correction

I added a four-second boundary, reduced context gracefully when retrieval was slow, and supplied a safe fallback assistant. A slow dependency now reduces answer quality instead of losing the call.

Customer-ready design: communication paths resolve tenant context from the request, then load that business's identity, knowledge, tools, calendar, and operating rules.

Proof 2 · Live

Preserve identity from the first visit to later CRM activity

I treated attribution as a durable identity and event problem rather than a browser-pixel feature. The system captures campaign and visitor context, recovers it when a later CRM event arrives, and delivers the normalized event independently to Meta, GA4, Google Ads, TikTok, and LinkedIn.

1,766

Tracked events

Current system activity, including browser, engagement, and funnel events.

5

Destinations

Each receives events independently so one failure cannot block the others.

140

Delivery audits

Recorded platform attempts. They are not presented as 140 customer conversions.

1

Shared contract

Website and CRM sources use the same conversion logic and evidence trail.

The decisions that matter

Database uniqueness prevents retried webhooks from creating duplicate sends. Platform failures are isolated. Test traffic stays visible internally but is withheld from advertising optimization. Atomic data updates stop concurrent enrichment from erasing unrelated event details.

Proof 3 · Built and Working

Turn prompts into reusable operating procedures

The skills library contains 45 current skills and 12 composed workflows across research, positioning, writing, SEO, creative production, browser work, publishing, video, knowledge, and engineering. The count is not the important part. The operating contract is.

01

Inputs

What the employee must know before it starts.

02

Procedure

Deterministic steps, judgment rules, examples, and counterexamples.

03

Authority

Which tools and actions are allowed, gated, or prohibited.

04

Evidence

What must be recorded to prove completion and improve the next run.

Assignment routing chooses the most specific match, fails closed when routes are ambiguous, uses a bounded last-known-good result during temporary failures, and records assignment context with the work. Focused routing tests pass.

Customer-ready design: the skill library and assignment-routing model provide the operating standard. Each business can receive its own assignments, evaluation cases, permissions, and authority without changing the underlying runtime.

Proof 4 · Live CRM Path

Book against real state instead of invented availability

The normal path

The agent queries the configured calendar, offers actual openings, finds or creates the customer, and writes the appointment into the business's operating system.

The awkward final mile

If another person takes the slot between search and booking, the tool returns the conflict and requires a fresh availability check. Communications are stored first-party before optional CRM synchronization, and failed contact creation can resume from persisted state.

Customer-ready design: A platform-agnostic CRM router allows each customer's operating hub to be configured at the tenant layer while preserving the same employee, assignment, communication, and attribution model.

Proof 5 · Working Components

Bound autonomy and make failure recoverable

Agent quality is not only the model's answer. It includes whether the system used the right context, stayed inside its permissions, requested approval at the right time, recorded what it changed, and could recover after a provider or process failed.

Controls already built

  • Tool permission gates and persisted approval records
  • Database-backed retries and duplicate protection
  • Dependency health checks with hard time limits
  • CRM credential and write canaries

Evidence already produced

  • Twelve scored voice-agent simulation scenarios
  • Assignment-routing tests covering ambiguity and failure
  • Logged production and internal workflow activity
  • Explicit rollout, rollback, and escalation requirements

Customer-ready design: these controls make customer deployment safe. Every assignment can carry its own permissions, approvals, escalation rules, evidence, and scorecard while preserving the same operating model.

Breadth With Boundaries

The rest of the system supports the story. It is not the headline.

Research and production

Market, keyword, competitor, website, search, and social research tools feed a staged content and creative pipeline. A programmatic video engine has produced verified media outputs.

Tools and deployment

Agents can work through APIs, CLIs, browser automation, database tools, and an MCP router. The live stack runs across Fly.io, Cloudflare, Supabase, Vapi, Twilio, and GoHighLevel.

Some complete pipeline runs have failed on provider quotas and malformed model output. Not every capability runs in every workflow by design. Additional links are activated when an operating need justifies them, and the failures already observed shaped the recovery architecture.

Two Corrections

The mistakes that changed how I build

01

Every external dependency eventually hangs

The live-call failure changed my default. Dependencies receive time limits, degraded modes, visible errors, and recovery behavior before they sit on a consequential path.

02

Technical capability does not earn product scope

I proved several capabilities before one repeated customer workflow had earned the full surrounding system. If I restarted, I would begin with one consequential workflow, instrument its real use, and expand only after the evidence justified additional scope. Autonomy and complexity are earned one bounded responsibility at a time.

What I Am Looking For Now

A new challenge with one team and one consequential product

I spent 1.5 years building and operating 1000x Sales and its underlying AI systems. I am no longer actively operating the company. I am now looking to commit full-time to a team where I can apply this zero-to-one range against a focused customer problem and a tighter feedback loop.

I am most useful close to customers and the product: finding the real constraint, building the smallest useful version, watching where it fails, and hardening only what earns the right to scale.