How We Run Internal Business Management with Aether

Field-service companies live and die on operational clarity: stale quotes, unscheduled crews, overdue invoices, dispatch mismatches. Most teams handle that with dashboards, spreadsheets, and ad hoc scripts. At Service Velocity, we took a different path—we built an internal business management layer on Aether, our agent execution language, and wired it directly into the same Service Velocity API the product uses.

This post explains what that internal layer does, why we built it this way, and enough of the language to show why it is not a chatbot glued onto Slack.

The problem we were solving

AI assistants are easy to demo and hard to operate. Without structure, you get:

• Agents that can “do anything” but shouldn’t
• Outputs that sound confident but aren’t grounded in live data
• No clear line between read, recommend, and act
• No audit trail when something goes wrong

Service Velocity is a B2B field-service platform—dispatch, scheduling, quotes, jobs, invoicing, mobile field apps, role-based access, and customer communications. Our internal ops team needs the same rigor we expect from the product: least privilege, human approval on high-impact actions, and traceability.

So we didn’t bolt a chatbot onto Slack. We built an AI company operating system—a governed multi-agent suite with a Service Velocity vertical extension—and expressed it in Aether.

What this means in practice

The company suite is a generic operating system: CEO goals, department lanes, quality review, shared memory, audit logging, and approval gates. The Service Velocity extension plugs in field-service-specific agents, workflows, and commands—all scoped to approved API access and internal safety rules.

Orchestration, not a monolith assistant

Work enters through a chief orchestrator that classifies intent and routes to department lanes—sales, marketing, ops, finance, HR, legal, customer success, product, engineering, data, security—or to product-specific Service Velocity work.

Each lane has scoped tools, memory categories, and cost and turn limits. Risky outbound integrations go through an integration steward and host allowlists. Not every agent gets HTTP access.

Live read-only operations

Internal agents call the same HTTPS API the product app uses—with Entra auth, tenant headers, and a catalog of approved read-only endpoints. Briefs and reviews are grounded in live tenant data, not hallucinated counts.

Core operational workflows include:

• A CEO-style daily ops brief
• A scheduling-focused risk scan
• Client context and search
• Quotes, invoices, and payments rollup
• KPI and executive dashboards
• Plan and execute catalog-approved API reads

Cross-area business review

One deterministic pass runs across quotes, requests, jobs, invoices, and scheduling. It surfaces issues by area and severity: stale quote drafts and sent quotes with no response; accepted quotes without a job; aging requests; unscheduled or overdue jobs; completed work awaiting invoicing; overdue invoices; unassigned appointments, crew skill mismatches, low margin; double-booked crews, missed appointments, crew day overload.

If API calls fail, the report leads with data unavailable—never a false “all clear.” The service manager role runs this review first in daily workflows. Fixes still route through approval gates. Read-only analysis never silently mutates production.

Dispatch and manager approvals

Dispatch operations add a two-week analysis layer with outcome proposals—crew compatibility, assignment recommendations, and platform approval enqueue. Managers approve in the product dashboard. Gated writes execute only after explicit approval.

Growth and executive planning

Beyond day-to-day ops, the growth layer produces multi-department operating plans: company growth plans, OKRs, department scorecards, initiative backlogs, and operating rhythm. Executive dashboards mark explicit data gaps when metrics aren’t connected. KPIs default to unknown until real data sources are wired—we don’t fabricate numbers for executive reports.

Documentation vault

Internal agents search a mirrored documentation vault—API, mobile, marketing, access control, operator runbooks—and cite canonical docs instead of guessing. Support, operator triage, and marketing website audits all use this vault as source of truth.

That vault is ours, not a customer knowledge base. In the product, Spaces have no per-Space or per-agent corpus except Docs / help, which is a static product guide. How product agents actually work.

Customer safety and write governance

By default:

• API access is read-only on catalog-approved paths
• Customer-facing actions require explicit gates and allowlists
• Email and SMS flow draft → write plan → CSR and approval officer → apply
• Every write clears lifecycle preconditions, customer safety checks, and approval tokens
• Writes are audited and persisted as plans

Simulation mode stubs models and tools so teams can dry-run workflows before live tokens or production impact.

Quality, evidence, and improvement

Workflow outputs pass through quality checks: pass, rework, escalate, or fail. A swarm improvement loop scores maturity from router-only to self-improving, tracks stale work, and runs governed improvement passes—assessment, governance, memory, prioritized plan, approvals, audit.

Why a language, not just Python glue

Aether treats agents, tools, schemas, memory, workflows, and policy as native constructs—not strings and SDK calls scattered across repos. Ops logic needs the same discipline as product code: parseable, testable, reviewable, and deployable.

Three execution modes support the full lifecycle:

• Interpreted — fast iteration during development
• Bytecode — production deployment without shipping the interpreter
• Native compilation — standalone binaries for edge or performance-sensitive workloads

Language surface (collapsed)

The same toolkit powers the Service Velocity internal layer and other agentic systems we build on this foundation:

• Foundations — types, collections, control flow, functions, async, JSON, assertions
• AI and agents — models, schemas, permissioned tools, ask expressions, workflows, multi-agent messaging and consensus, prompt templates
• Memory and knowledge — local and shared stores, explicit remember and recall, retrieval and ranking
• Resilience — try/catch around tool and agent failures, plans with replanning and rollback, checkpoints, cost and turn budgets
• Governance — guards and policies, simulation mode, provenance and citations
• Interoperability — call out to Python and other runtimes; Model Context Protocol in both directions
• Tooling — interpreter, bytecode VM, native backend; run, test, check, packages and modules

What this means for Service Velocity customers

Customers don’t run Aether directly—they run Service Velocity.

The internal layer still matters because:

• Operational intelligence is product-adjacent—the same API, access control, and lifecycle model the product exposes is what internal agents read and (when approved) act on.
• Safety is structural—not a prompt asking the model to “be careful.”
• Improvement compounds—vault-backed docs, quality loops, and maturity scoring make the internal ops layer get better over time.

We’re building field-service software where the team operating the platform uses the same architectural discipline we ask of the product itself.