Articulation of what Outfitter does, in language a trade owner can hear in 30 seconds and a salesperson can deliver without notes. Use as the source for lead-gen scripts, discovery openers, and cold outreach.
Outfitter is a team of AI workers that run the back-office of your trade business — answering calls, chasing quotes, doing the marketing, keeping the books — so you stay in the field doing the work that pays.
That's the only sentence you really need. Everything else is elaboration.
Elevator pitch. Lead-gen opener. The "what do you do" answer at a barbecue.
We give trade business owners a team of AI workers. There's an AI receptionist that answers every call 24/7, qualifies the lead, and books the job on your calendar. There's an AI revenue manager that follows up on every open quote until it closes or the customer says no. There's an AI marketing manager that runs your ads, sends your campaigns, requests reviews, and posts content. They work whether you're already using Jobber, QuickBooks, ServiceTitan — they plug into what you've got. Or if you don't have any of that, we have our own simple stack built in. The result is a back office that runs itself.
The part that surprises people. It's not a chatbot on a website. It's a team that works across every channel they already use — with full memory across all of them.
The owner picks up the phone and has a five-minute conversation about a complicated estimate. Five minutes later, they send a text with an update. The next morning, they log into the workspace on their computer. Across all three touchpoints, the context is consistent — the agent remembers what was discussed on the call, picks up the thread from the text, and ties it all together in the morning session. Exactly the way it would work with a real person on your team.
The four channels — all connected, all in sync:
Call in and speak naturally. Ask a complex question, think through a decision, escalate an urgent issue. The agent responds in real time and remembers the full conversation.
Fire off a quick update from the truck or between jobs. The agent responds in seconds. That context is now part of the thread.
Forward a thread, send a document, ask something that needs a longer answer. The agent handles it and logs the exchange.
Log in for anything that needs a screen — reports, dashboards, reviewing what the agents have done, running plays. Everything from the phone calls and texts shows up here.
The context follows the owner — not the channel. Same thread, same memory, same agents, wherever they happen to be communicating from. That's not how software works. That's how people work.
Use this in discovery calls.
Look — every owner I talk to is doing the same thing. You're on a roof at 10am, then you're doing estimates until 11pm, your wife's mad, your books are three months behind, and you missed eleven calls this week because you couldn't pick up.
Outfitter fixes that by hiring you a team. Except instead of hiring people, you're activating AI workers — each one trained for a specific trade (HVAC, plumbing, electrical, roofing) and a specific domain in your business (sales, marketing, finance, operations). So:
Answers every call, 24/7. Sarah Lin calls about a busted AC at 7pm — the agent picks up on the first ring, sounds completely human, asks her three qualifying questions, sees you're free Tuesday at 9am, books her in, sends her a confirmation text. You wake up Tuesday morning and Sarah's on your calendar.
Watches every open quote. You sent the Rivera bath quote five days ago and they haven't signed. The agent emails them a friendly nudge, sees they opened it twice, calls them on day seven, finds out they need three days to talk it over with their spouse, schedules a callback, books the close. You did nothing.
Posts content on your Google profile, runs your ad spend, sends review requests after every completed job, and writes your monthly EDDM postcards. You approve a stack of work once a month. The campaigns run themselves.
Reconciles your QuickBooks every Sunday night, flags the jobs that are losing money, sends invoices the day work completes, follows up on past-due ones. You stop being the bookkeeper.
Runs payroll across Gusto, ADP, or Paychex — whichever you use. Posts your tech opening to Indeed, LinkedIn, ZipRecruiter, and Google for Jobs in one shot, pulls applicants into one place, schedules interviews. Tracks PTO and benefits, onboards new hires, keeps 1099 contractor records audit-clean. You stop being the office manager.
These are real agents doing real work. Not "AI helps you do" — actually doing it.
Now the second half of the pitch: we don't ask you to switch your software. The agents work on top of whatever you're already using. If you're on Jobber for scheduling, the Front Desk Agent books straight into Jobber. If you use ServiceTitan for dispatch, the Operations Agent dispatches in ServiceTitan. If your books are in QuickBooks, the Accounting Agent runs QuickBooks. We integrate with all of it — that's the whole point. We don't want your data locked in our system. We want to run the work wherever your data lives.
If you DON'T have software yet for something — say you've never had a CRM — we have our own simple version built in. It's not the headline; it's just the place the agent works when you don't have anything else. Most customers end up using a mix: keep Jobber, drop their answering service, use our marketing tool because they never had one. Whatever fits.
This is the question that always comes up.
The agent is the product. The tool is wherever it works.
If they're already on Jobber: "Great. Keep Jobber. Our agents run Jobber for you. You stop logging in, the work still gets done."
If they're already on ServiceTitan: "Same answer. Our agents work in ServiceTitan. We're a brain on top of your existing stack."
If they have nothing: "Then start with our stack. It's simple, it's cheap, the agents work natively in it. You can always migrate to something bigger later — most don't."
If they ask "are you a Jobber competitor?": "No. Jobber is software you operate. We're a team that operates the software. Different category."
The other unknown when we walk in the door. Same answer pattern: we meet them where they are.
We don't know what software they have. We also don't know what people they have. Most trade businesses have at least one of: a spouse or family member answering calls, an office manager doing scheduling and books, a dispatcher running the daily plan, a bookkeeper handling QuickBooks, a part-time virtual assistant. Some have all of those. Some have none. The agents have to work in either world.
We don't replace your team. We give them superpowers.
Specific responses, by role:
"Great. Your receptionist still answers during business hours. The agent picks up after hours, on weekends, and during overflow when she's on another line. She goes from missing 30% of calls to missing zero — and her workload drops because the agent handles routine intake. She handles the customers who actually need her judgment."
"Perfect. The agent does the busywork — drafting follow-ups, entering data, generating reports, flagging quotes that are aging. Your office manager reviews and approves. She goes from data entry to decision-making. Higher-leverage role, same person, no firing required."
"Same pattern. The agent makes the obvious dispatch decisions — assign the AC repair to the closest tech who's free at 2pm. Your dispatcher handles the edge cases — the customer who's particular, the tech who needs to leave early, the route that needs creative routing. The agent does 80%, your human does the 20% that requires judgment."
"Agent reconciles transactions, drafts entries, flags anomalies, sends invoices. Your bookkeeper reviews, approves, and spends her time on strategic work — tax planning, margin analysis, cash forecasting. She becomes a CFO, not a data-entry clerk."
"That's why most owners are working until midnight. The agents take the whole load. You're the human in the loop until you decide to hire. Most don't end up needing to."
The customer also chooses the level of autonomy for each agent. Three modes:
Agent prepares the work — drafts the email, fills the quote, queues the dispatch — and waits for a human to approve before action. Highest oversight, slowest output. Use this for the first week or two.
Agent takes the action and tells the human what it did. Lower-stakes work runs immediately, the team sees a recap. This is the default after a week or two — agent earns trust by showing its work.
Agent acts without human review for routine, predictable work — booking standard appointments, sending review requests, reconciling routine QBO transactions. The high-stakes calls (large quotes, irregular customers, escalations) still surface for review. This is where most operators end up after a month.
It's the same way you'd onboard a new employee. Watch closely at first, supervise the work, then let them run when they prove themselves. The agents earn autonomy the same way.
When you put it all together, this is the master framing.
Every prospect lives somewhere on two axes:
Could be Jobber, ServiceTitan, Housecall, QuickBooks, ADP, Google Workspace, custom spreadsheets, or nothing. Our answer: agents work via MCP across whatever they've got. If they have nothing for something, our internal stack covers it.
Could be a spouse, an office manager, a dispatcher, a virtual assistant, or nobody. Our answer: agents work alongside whoever they've got. Augment, don't replace. If they have nobody, agents take the whole load until the owner decides to hire.
The pitch handles every quadrant of those two axes the same way: tell us what you've got and we plug into it. No discovery calls about replacing systems. No conversations about laying off the team. The agents work with what's already there.
The plain customer answer. The technical depth on architecture, action library, plays, and roadmap lives in Part 2 at the back of this document.
An agent is a worker that handles a specific job in your business. The Front Desk Agent answers your phone. The Revenue Agent chases your quotes. The Marketing Agent runs your campaigns. The Accounting Agent reconciles your QuickBooks. The HR Agent runs payroll and hires your next tech. You tell it what you want, set how much oversight you want to keep, and it goes. You can watch what it's doing, change its instructions, or pause it any time.
That answer is enough for the customer conversation. For prospective hires, technical partners, or investors who want to understand the engine — how agents are organized, how the action library works, how plays compose, how we integrate via MCP versus our own internal stack, and where the platform is heading as the AI industry matures — Part 2 at the back of this document goes deep.
Every agent can do three categories of work. They build on each other — and together, they cover almost anything a back-office team member would handle.
The agent can surface any piece of information, context, data, or research connected to the business. The open quote from three weeks ago. The customer's payment history. What other HVAC businesses are charging for maintenance agreements. The last five jobs that ran over budget. Finding this — especially across different systems, in the details — goes from a 20-minute dig to asking a single question.
The agent helps think through decisions. Weigh options. Run the pros and cons. Is this even a priority? What are other operators doing? What does your own data say? Whether the question is "what should I say in this email" or "should we open a second service zone next spring," the agent can ground the decision in real data and the owner's stated priorities — not just the first thing that comes to mind.
The most transformative tier: the agent completes the functional steps. An email needs to go out — it goes out. A call needs to happen — it happens. A meeting, a report, a follow-up, a data point to monitor, a piece of sales content — the agent delivers. This is the shift from "AI helps you do work" to "AI does the work." And it's where most owners stop being skeptical and start asking when they can start.
Three buckets. Hundreds of plays in each. Custom plays for anything outside them.
Most owners think about “help” in three different categories. Our agents work across all three.
EXPAND — capabilities you don’t currently have, because at your scale you couldn’t run them. After-hours coverage. Outbound follow-up on every dead lead. A real marketing engine. Things that were always reserved for the bigger company down the road.
UPGRADE — what you already do, done cheaper, faster, or more consistently. The same intake call, every time. Quote follow-up that actually happens. Books that close on the day instead of at the end of the month.
RECLAIM — work you can stop doing yourself entirely. The phone. The reminder texts. The dispatcher’s whiteboard. The afternoon you lose every week to QuickBooks. The hours that should have been yours to begin with.
Hundreds of pre-built plays in each bucket across HVAC, plumbing, electrical, roofing, landscaping, and GC. If a play doesn’t exist for what you need, we build it custom.
The most important explanation in the entire pitch. Once a customer gets this, they understand why "AI features" in Jobber are not the same thing as Outfitter.
Software was built around a constraint: humans operate it one step at a time. We have one set of eyes, one attention span, two hands. So pages are linear. Forms are linear. Workflows are linear. The whole design of business software for the last 30 years exists to help a human do the next-one-thing slightly faster. Open Jobber. Click Estimates. Find Quote #2847. Open it. Read it. Decide. Click follow-up. Type the email. Click send. One step at a time.
Agents collapse all of that into parallel. The same work, but done all at once instead of one-at-a-time. This isn't a feature improvement. It's a categorically different way of operating a business.
Software was built to help humans do work one step at a time. Agents do all the steps at once.
Three phases of work, all of which collapse from serial to parallel:
While a human opens one tab, then the next, then the next — the agent ingests Jobber, QuickBooks, Gmail, Google Ads, the phone system, and everything else in parallel, in seconds. The agent doesn't context-switch between systems. It reads them as one big picture. Cross-system intelligence becomes natural, not a feature.
The agent looks at every open quote, every customer's payment history, every recent call, every campaign's performance — together — and decides what should happen in each case as a single coherent judgment. A human reviews 50 quotes one at a time and runs out of attention by quote 12. The agent reviews 50 quotes as a single piece of context and produces 50 decisions in one pass.
Once decisions are made, the agent fires off 47 follow-up emails simultaneously. Schedules 12 voice calls in parallel. Updates 30 QuickBooks transactions, posts to your Google Business Profile, and queues 5 dispatch assignments — all at the same time. Limited only by API rate limits, not by human-paced clicking.
The compounding outcome: a task that takes a human four hours of clicking through screens takes the agent four minutes. A weekly review of every customer in your database — something most owners never do because it's too tedious — can run overnight, automatically, while you sleep. The owner wakes up to a list of decisions made, actions taken, and recommendations queued.
This isn't 2x faster. For the right kind of work — anything that involves looking at lots of information and taking lots of small actions — it's 50-100x faster. That's the real time-savings claim. And it's why "AI features" inside legacy software (a smart auto-fill, a chatbot helper) is not the same product as an agent. Features still leave the human doing the work serially. Agents do it in parallel.
Use it as your sign-off, your tagline, your LinkedIn header.
You run the field. We run the rest.
Every conversation starts there, every conversation ends there. The agents do the rest. The tools are wherever the work lives.
Pick the one that matches the channel.
"Are you still paying $49/mo for Jobber's Receptionist add-on? We give you a better one for free. AI, 24/7, books straight to your calendar. Worth a look?"
"How many calls did your business miss this week? We have an AI receptionist that catches every one. Free. Want to hear it?"
"Most trade owners I talk to spend 15 hours a week on follow-ups, books, and marketing. We give you a team of AI workers that does it for you. Want to see what your week looks like without it?"
Those three together cover most lead-gen contexts.
Written for engineers, technical hires, product partners, and operators who want to understand the system underneath the customer pitch. The customer answer ends at "the agents do the work." This section is the engine.
Outfitter is four primitives glued together by an integration layer and steered by a control plane. Understanding the four primitives and how they relate is enough to understand 90% of how the product works. The other 10% is implementation detail. The four:
Actions — atomic capabilities (verbs)
Agents — domain-scoped roles that compose actions to complete goals
Plays — orchestrated multi-step workflows that execute business outcomes
Playbooks — curated collections of plays for specific business contexts
Every other piece of the system — the integration layer, the management center, the autonomy controls, the observability surface — exists to make those four primitives reliable, composable, and operator-controllable.
An agent is a configured role, not a model. The same underlying LLM (currently Claude Sonnet/Opus) powers every agent. What differentiates them is configuration — scope, persona, allowed actions, goal function, autonomy level, escalation rules. This means upgrading the model upgrades every agent simultaneously. We swap brains without rebuilding products.
Each agent carries:
A persistent ID, a name, a domain, an owner (the customer). The agent's identity is durable across sessions — when an action audit log says "Front Desk Agent booked Sarah Lin's appointment at 7:42pm," that's traceable to a specific agent instance running for a specific customer.
The set of actions the agent is allowed to call, the data sources it can read, and the boundaries of its decision-making authority. Scope is enforced at the action layer — if the Front Desk Agent tries to call send-invoice, the action layer rejects it. This is how we prevent agents from wandering outside their lane.
Tone, voice, default response patterns, escalation language. The Front Desk Agent's persona is warm-but-efficient. The Revenue Agent's persona is persistent-but-not-pushy. Persona shapes how the agent communicates externally — to customers, vendors, employees.
What the agent is optimizing for. Front Desk Agent maximizes booked appointments while minimizing customer friction. Revenue Agent maximizes quote close rate while preserving the relationship. The goal function is what the agent uses to choose between competing actions.
Per-customer setting (Draft / Notify / Autonomous) that controls how much human review each action requires. Set globally per agent or per-action. New customers default to Notify mode and graduate to Autonomous as trust builds.
Domain organization. Agents are grouped into domains that mirror the functional structure of a trade business: Sales (Front Desk, Revenue), Operations (Dispatch, Field Operations), Marketing (Campaigns, Reviews, Content), Finance (Books, Cash Flow), Intelligence (Briefings, Benchmarks). The domain structure isn't just a UI grouping — it's how we control the action library's scope graph and how plays orchestrate cross-functionally.
Agent relationships. Agents can hand off to each other. A Front Desk Agent that catches a "interested but not ready" lead can hand off to the Revenue Agent for a follow-up sequence. The handoff carries full context — call transcript, qualification answers, customer preferences. This is how cross-domain plays work.
Actions are the atomic units of work. The library is shared across all agents and all customers. Every action is:
Strict input/output schemas. send-email(recipient, subject, body, attachments[]) → {messageId, status}. Type safety means agents can't construct malformed actions, and the action layer validates everything before execution.
Each action knows where to execute. send-email might route through SendGrid for our internal stack, or through the customer's Gmail via MCP, or through Mailchimp via their API — depending on customer configuration. The agent doesn't know or care; it just calls send-email. The action library figures out the right execution path.
Actions evolve. v2 of send-quote might add e-signature support. We can roll out new versions to subsets of customers, A/B test, and roll back without breaking running plays.
Every action call is logged with full context — the agent that called it, the input arguments, the execution path (internal vs MCP vs Computer Use), the output, latency, errors. The audit log is the customer's source of truth for "what did the agent actually do?"
Each action declares which agent domains and autonomy modes can call it. charge-customer-card requires explicit owner-level authorization. send-review-request can run on Autonomous mode for routine cases. The permission graph is enforced at the action layer, not relied on at the agent layer — this is a defense-in-depth design.
The action library is our most-leveraged asset. Every new action ships once and immediately becomes available to every agent that needs it across every customer. The library compounds — at 200 actions we can compose plays we couldn't dream of at 50 actions, and at 1000 actions the system reaches a level of coverage no incumbent can match without rebuilding their product.
A play is a workflow — a directed graph of actions, often spanning multiple agents, with branching logic, failure handling, and success criteria. Plays are how we encode operational best practices into reusable, executable form.
Plays are:
Built from existing actions in the library, plus control flow primitives (if/else, parallel, sequential, wait-for-event, retry-on-failure). New plays are configuration, not engineering — most plays are written in our internal play-builder UI in 30-60 minutes.
Plays don't just sit there. Triggers fire them: event-based ("a new lead came in"), schedule-based ("every Sunday at 6pm"), threshold-based ("when open quotes > 10"), manual ("owner clicked Run"). One play can have multiple triggers.
A "Stale Quote Follow-Up" play ships as a default. Customers can clone it, edit it (change the wait time from 5 days to 7, change the email template, add a Voice AI step), and run their custom version. Updates to the source play don't overwrite customer customizations — they merge cleanly.
When a play runs, every step is visible. The owner sees: "Stale Quote Follow-Up triggered for Rivera Bath. Step 1 (send-email) succeeded at 9:14am. Step 2 (wait 48hrs) in progress. Step 3 (queue-voice-call) pending." If a step fails, alerting kicks in — for the owner, the customer success team, or our engineering team depending on the failure mode.
A playbook is a curated bundle of plays for a specific business context. The "HVAC Spring Tune-Up Playbook" might include 12 plays — outbound campaigns for maintenance reminders, inbound qualification for tune-up requests, dispatch optimization for the seasonal volume spike, post-job review requests, follow-on equipment-replacement nurture sequences. A customer activates the playbook and gets the full operational framework, pre-built and pre-tuned for their trade and their season.
Playbooks are how trade-specific intelligence gets packaged and shipped. A new HVAC customer joins Outfitter on March 15 and immediately gets the HVAC Spring Tune-Up Playbook activated — they're operating like a top-decile HVAC business on day one, without having to build anything themselves.
The same agent, calling the same action, can execute against two different destinations. This is the architectural insight that lets us be agnostic about where the customer's work lives.
MCP path: agent acts in the customer's existing tools. Our internal stack: agent acts in our own modules. Same agent. Same action. Different destination.
MCP path — for customers with existing tools. The agent calls send-quote. The action layer recognizes that this customer has Jobber configured. It routes the call through the Jobber MCP server, which calls Jobber's API to create the quote inside the customer's Jobber instance. The customer's data never leaves Jobber. We never become the system of record. We're a brain on top of their existing stack.
This path applies to: QuickBooks (books and invoicing), ADP (payroll), Google Workspace (calendar, email, ads, business profile), Jobber/ServiceTitan/Housecall (CRM and dispatch), Stripe (payments), Twilio (SMS/voice), Salesforce, HubSpot, Mailchimp, and the long tail of vertical SaaS. Each integration is a separate engineering investment but uses the same MCP wrapper pattern, so per-integration cost decreases as the team gets faster.
For tools that don't expose APIs — or expose them but gate the most valuable actions behind UI — we layer in Computer Use: the agent operates a browser the way a human would, clicking and typing through the tool's UI. Anthropic shipped Computer Use in 2024 and it's maturing rapidly. By 2026 we expect to credibly say "we work with anything you've got" — including legacy desktop software, niche industry tools, government permitting systems, and internal portals.
Internal functionality stack — for greenfield customers and customers who want a unified surface. The agent calls send-quote. The action layer recognizes that this customer doesn't have an external CRM configured. It routes the call to our internal Sales Suite, which generates the quote in our system. The customer accesses it via our Client Portal, signs via our e-sig, the resulting deal lives in our pipeline.
Our internal stack covers what overlaps with workflow SaaS: estimating, scheduling, customer portals, invoicing, messaging, dispatch, project management, basic CRM, basic reporting. We don't rebuild commodity infrastructure — Google Calendar, QuickBooks, ADP, Stripe — because those are regulated, network-effected, or simply better-built than anything we'd ship in 18 months. We use them via MCP.
The key design decision: the internal stack is not a competitive offering against Jobber. It's the agents' default operating environment when the customer hasn't already invested in something else. We don't try to be a better Jobber. We try to be invisible — a place the agents work when there's nothing else, easy to migrate off if the customer outgrows it.
The customer's journey:
Activates Outfitter. Uses our internal stack for everything. Agents work natively. As they grow, they may eventually migrate the heavy stuff (e.g., enterprise dispatching) to a specialized tool — at which point our agents reroute to the new tool via MCP without the customer noticing the switch from their daily-use perspective.
Activates Outfitter. Connects their existing tools via MCP. Agents work in those tools. Our internal stack stays dormant. As they encounter gaps in their existing tools (e.g., no AI receptionist, no client portal), they may activate parts of our internal stack to fill the gap — without abandoning Jobber. Hybrid is the steady state for most customers.
Either way, the agents are the product. The surface is wherever the customer's work lives.
This is the technical roadmap, written for an engineering audience. Each item is a real, public direction in the AI industry. Our job is to absorb each capability as it stabilizes and turn it into product. We do not have to invent any of these — they are coming whether we participate or not. Our advantage is the architecture is built to absorb them without rewrites.
Anthropic's Computer Use API exists today but reliability and speed are still maturing. As it gets faster and more reliable through 2026, the long tail of "tools without APIs" closes. We will absorb every improvement Anthropic ships. Our architecture treats Computer Use as just another execution path inside the action layer — we don't have to rebuild anything to take advantage of it.
Today's plays are mostly linear. The next pattern, already shipping in Claude Code and frameworks like LangGraph and Anthropic's Agent SDK, is hierarchical: an Orchestrator agent spawns specialized sub-agents for sub-tasks, coordinates their work, and composes the result. Complex jobs (storm response, multi-stakeholder permitting, parts ordering across vendors) become naturally expressible. We absorb the patterns as they stabilize.
The frontier in agent architecture is persistent memory — agents that remember customer preferences, outcomes, decisions, and patterns across months and years. Anthropic, OpenAI, and several memory-specific platforms (Mem, Letta) are pushing on this. As it matures, every Outfitter customer's agents become uniquely theirs — institutional memory of their business, their voice, their team, their playbook. This compounds: the longer a customer runs Outfitter, the harder it is to switch, because their agents have learned them.
Currently we use voice and text. Vision is the next frontier — agents that can read job photos from the field, parse receipts, recognize equipment, evaluate site conditions from a tech's iPhone camera. Anthropic's Claude has vision; deployment patterns are still maturing. Adding vision turns the Field Operations Agent into something that actually knows what's happening on the truck. Entire categories of agent behavior become accessible.
Anthropic launched Skills as a way to give agents specialized, contextually-activated abilities — a "permitting" skill that activates only on California HVAC questions, a "storm-response" skill that activates only during severe weather. Skills let an agent carry a deep library of trade-specific, region-specific, or customer-specific expertise without bloating its core. We treat Skills as a separable layer that any agent can compose with its action library.
Today's Front Desk Agent uses a generic-but-warm voice. In 12-24 months, every customer's Front Desk Agent will sound like their actual receptionist (with permission), match their brand language, reflect their pricing tiers and quirks. Fine-tuning APIs from Anthropic, OpenAI, and others are advancing. The architecture supports per-customer model configuration today; we're waiting on the cost-quality curve to cross.
Anthropic's Claude Opus and OpenAI's o-series models can reason longer for complex decisions, trading speed for accuracy. Most agent calls don't need it. But for high-stakes moments — a $50K quote negotiation, a customer threatening to cancel, a legally-sensitive complaint — the agent should switch into deep reasoning mode. The action layer routes these decisions to the more expensive model, then back to the standard model for execution. Hybrid model orchestration is becoming a standard pattern.
The industry is building tooling for agent evaluation at scale. Anthropic's Evals, OpenAI's Evals, third-party platforms (LangSmith, Helicone, Langfuse). Our roadmap includes continuous benchmarking of every agent: qualification rate, booking rate, customer-satisfaction scores, regression tests on every prompt change. Quality becomes provable, not anecdotal.
An emerging frontier: agents talking to agents across organizational boundaries. Our customer's Front Desk Agent could negotiate parts pricing with a supplier's order-taking agent. Standards like Anthropic's MCP, plus protocols still emerging from the industry (Agent2Agent, ACP), point toward an agent web. We're early enough to design for it.
Agents authorized to spend money on the customer's behalf within budget and policy constraints. An Operations Agent that auto-orders parts when inventory dips, charged to a budget the owner authorized. A Marketing Agent that auto-allocates ad spend across channels based on real-time performance. Identity, authorization, audit, and reversal infrastructure for this is being built across the industry. We absorb it as it matures.
Currently we use ElevenLabs and ElevenLabs for voice. Real-time interruption handling, emotional context detection, multi-language, regional accents — all advancing rapidly. Anthropic's voice efforts plus the broader voice-AI infrastructure (OpenAI Realtime, ElevenLabs, Retell) keep pushing the realism bar. Every improvement upstream is a free product upgrade for us.
Above the architectural compounding is a more fundamental shift worth naming explicitly, because it's the underlying physics of why agents are categorically different from software.
Traditional software is shaped by the constraint that humans operate it serially — read one screen, decide one thing, click one button, repeat. Every UX decision over 30 years of SaaS has been optimized for this serial workflow. The agent stack inverts the model: read everything in parallel, reason holistically over the full context in a single pass, execute many actions concurrently. Each phase compresses from hours of human time to seconds of agent time.
Three layers make this possible:
Where a human opens tabs sequentially and context-switches between systems, the agent issues simultaneous calls across every connected platform. Twenty MCP servers can return data in the time it takes a human to find one tab. The wider the integration footprint, the more pronounced the parallelism advantage becomes.
Modern LLMs (Claude Sonnet/Opus, GPT-4/5) handle hundreds of thousands of tokens of context in a single inference. This means a single agent call can take in the entire pipeline state, every customer's recent activity, every open quote, every campaign metric — and produce a coordinated set of decisions across all of them. It's not literally parallel CPU-style processing; it's holistic single-pass reasoning over a wide working memory. Functionally indistinguishable from "thinking about everything at once."
Once decisions are made, the action layer fires them in parallel. Forty-seven follow-up emails dispatched concurrently. Twelve voice calls queued simultaneously. Multiple QuickBooks transactions, Google Business posts, and dispatch updates all executing at the same time. Constrained only by upstream API rate limits, not by sequential execution.
The architectural implication is that agent value scales with how much information needs to be considered and how many actions need to be taken. Tasks that look at 50 things and take 50 actions are where agents are 50-100x faster than humans, not 2x. Most back-office work in trade businesses fits this profile precisely — review the open quotes, follow up the right ones, update the records, send the messages, post the content. Endless small parallel work.
This is why the legacy SaaS pattern of "add an AI feature to an existing product" doesn't capture the real value: the workflows themselves are still serial because they were designed for humans. Outfitter inverts the workflow design — every play is a parallel-execution graph, not a linear sequence. That's a structural property of the platform, not a feature.
Three observations explain why the system gets more valuable over time, not less:
The action library compounds. Every new action is reusable across every agent and every customer. Action #200 unlocks plays we couldn't compose at action #50.
The integration library compounds. Every MCP server we ship works for every customer who uses that platform. Integration #20 (e.g., ADP Workforce Now) immediately benefits every payroll-using customer in the base.
The play library compounds. Every play that works at one customer becomes a benchmarked, tunable starting point for the next. The first 50 customers reveal play patterns we haven't imagined; those patterns become the default for the next 5,000.
Three compounding loops, all running simultaneously, all reinforced by the platform's growth, all directly translatable to customer value. This is what makes the architecture defensible in a way that legacy SaaS isn't. A feature ships once and stops compounding. An action ships once and continues paying dividends every time it's reused. Same for integrations. Same for plays.
The bet is that the operator who runs Outfitter in 2027 has dramatically more capability than the operator who started in 2025 — without us shipping any new "features" in the conventional sense. The platform itself gets smarter and more capable as the libraries grow. That's the structural advantage.