AI in SaaS vs SaaS in AI: From Features to AI Coworkers

I like building things. Give me a problem, and my first instinct is to work out what we could ship: a better workflow, another integration, a cleaner dashboard.

But shipping a feature is only part of the job. The question I care about is what changes for the customer afterward.

What work can they now hand over?

A product can draft a reply, summarize a conversation, and recommend a next step. The customer may still have to move between systems, make the changes, chase missing information, and check that everything is finished. We have helped with individual steps while leaving much of the coordination with them.

I believe the next generation of SaaS has to take on more of that work.

At Birdeye, our AI coworkers bring marketing, operations, and customer experience together around business outcomes. Jay is our marketing coworker, Myna is our operations coworker, and Robin is our customer-experience coworker. Each coordinates specialist agents to carry work through its business function, with people setting the boundaries and deciding where approvals are needed.

That is why I believe in the AI coworker idea. It changes what customers can expect from software and what we, as builders, need to deliver.

When I delegate a task to a colleague, I expect them to understand the brief, work within their authority, follow through, and tell me where they need help. Bringing that expectation into software gives us a clear standard: useful work completed, a result we can verify, and meaningful control for the people relying on it.

This is the shift I mean by AI in SaaS versus SaaS in AI. Features remain important. The customer outcome gives those features a purpose.

Here is the distinction I use when thinking about product direction.

AI in SaaS adds intelligence to an existing software workflow: summaries, generated replies, recommendations, smarter search, or a conversational interface. The customer still coordinates much of the work.

SaaS in AI organizes software capabilities around an AI execution layer that can carry a defined task through to completion. Records, business rules, permissions, integrations, and actions become the tools it uses. The product checks the result and brings people in when needed.

These are two product patterns. A single product can contain both.

The distinction is not about whether a capability uses an LLM. It is about where the coordination work sits.

In the first pattern, the customer remains the workflow engine. In the second, the software takes responsibility for finishing the job within clear boundaries, with human oversight for exceptions and key decisions.

Our AI coworkers use multi-agent orchestration to bring the right agents together, pass work and context across them, and keep each step accountable to business rules.

Take Jay, our marketing coworker. Jay handles reviews, social presence, and listing updates across hundreds of business locations. Instead of asking a marketer to generate each post or review response manually, Jay coordinates the work across channels, applies brand guidelines, requests approvals where needed, and tracks what was published.

A coworker is defined by that responsibility, not by autonomy for its own sake. When people hear “agent,” they often picture an autonomous process deciding its own goals. In an enterprise product, open-ended autonomy creates unacceptable risk.

Our coworkers work within defined scopes. They use specialist agents for distinct tasks, operate against explicit permissions, verify what they did against underlying records, and bring in a person when judgment is required. The customer delegates the job without losing control over how it is performed.

Myna, our operations coworker, brings this approach to the front desk for healthcare and dental practices. It books, reschedules, and manages patient appointments around the clock through voice and messaging channels.

In a busy practice, scheduling is not a single conversational turn. A patient calls to move a Thursday cleaning. That conversation touches several software capabilities: identifying the patient, checking practice policies, reading provider availability, finding eligible slots, updating the practice-management system, sending a confirmation, and alerting staff if manual attention is needed.

An AI feature might answer the call, summarize what the patient said, or suggest three open appointments for a receptionist to review. The practice still has to carry out the change, send the confirmation, and check that the calendar is correct.

Myna takes on the job itself. It handles the conversation, books or reschedules the appointment directly in the practice-management software, verifies the update, and sends the confirmation.

To make that delegation work, we separate the output from the outcome and the business impact.

Now introduce a timeout. The scheduling request has been sent, but the response never arrives.

Did the change fail, or did the response get lost after the appointment was updated?

The workflow has to reconcile the actual booking state before retrying. Otherwise, a duplicate or conflicting confirmation can turn a helpful interaction into more work for the practice. If the state remains uncertain, that uncertainty needs to be visible in the handoff.

These are the details that make the AI coworker idea valuable. The conversation gets the work started. Reliable execution carries it through.

My starting point for an AI coworker is the job it is taking on.

“Help with the front desk” gives an engineering team very little to work with. “Reschedule an existing appointment within these rules” gives us a responsibility we can design, implement, and evaluate.

Before specifying models, tools, or prompt chains, we define what the product needs to establish:

Framing the product this way changes everyday engineering decisions. It is easy to spend weeks improving how natural a conversation sounds. If the appointment is not reliably updated in the underlying software, that polish does not deliver the outcome the practice needed.

Starting with the job keeps us focused on what matters: the boundaries of the task, the authority to act, the evidence of completion, and the path back to a human.

Delegating work should give people more room to focus. It should also make the state of that work easy to understand.

A dependable product needs to make three things obvious: what the coworker is handling, what it has completed, and where it needs help.

Jay posts content, responds to routine reviews, and flags critical feedback. Robin manages recurring customer questions, gathers context, and brings in the right team member when an issue needs personal care. Myna books routine appointments and hands off complex clinical requests, insurance questions, or scheduling conflicts to front-desk staff.

The handoff is where the design either succeeds or falls apart. If an escalation drops a receptionist into a blank screen with a raw transcript, the product has saved very little effort.

A useful handoff gives the person what they need to act: who the customer is, what was requested, what was already checked, what actions were attempted, and the specific decision required.

“The patient wants to move their Friday 2:00 PM cleaning with Dr. Chen to next week. Thursday at 10:00 AM is available, but that slot requires Dr. Patel. Practice policy requires confirmation before switching providers.”

That turns a confusing interruption into a five-second decision. Human oversight becomes more effective when the product respects the person's time.

An AI coworker needs access to the business's working environment.

A booking depends on location-specific availability. A review response depends on brand voice, past customer history, and whether the issue is already open in support. A marketing campaign depends on current promotions and recent performance across locations.

Without that context, even capable models produce answers that sound convincing but miss the operating reality.

We structure context across four layers:

1. Business rules and policies: What the coworker is allowed to do, what requires approval, and what is off-limits.
2. Operating state: Authoritative data from systems of record—calendars, listings, CRM records, inventory, and review feeds.
3. Domain knowledge: How this specific business operates—service descriptions, provider specialties, location hours, and common workflows.
4. Task history: What has already happened in this interaction, what actions succeeded, and what remained unresolved.

Treating context as architecture rather than a prompt-engineering problem makes coworker behavior more reliable. The models can be updated or replaced; the business rules and state integrations keep the work grounded in truth.

Feature usage tells us whether someone tried a capability. For an AI coworker, I also want to know what happened afterward.

How many eligible tasks were carried all the way through? How often was human intervention required? What did that intervention cost in time and attention? When the coworker finished, was the result correct in the underlying software?

We look at four operating dimensions:

1. Workflow coverage: What percentage of incoming requests fall within the coworker's defined scope?
2. Verified completion rate: Of eligible tasks, how many finished with a verified state change and no manual repair?
3. Handoff quality: When work escalates, does the handoff include the structured context needed for a fast, informed decision?
4. Downstream error rate: Did any completed action create duplicate records, invalid calendar states, or customer-facing discrepancies?

Measuring completion against the actual system of record keeps product teams honest. A conversational interface can claim success while leaving an unconfirmed appointment on the calendar. Only the verified record tells you whether the job was done.

An AI coworker does not need every step to be agentic.

Use code for rules that are already clear. Retrieve current information when the task depends on facts. Use an agent when the path involves judgment, interpretation, or selecting among tools. As Anthropic highlights in their guidance on building effective agents, starting with simple, composable patterns—routing, orchestrator-workers, and evaluator-optimizer loops—often delivers higher reliability than unconstrained multi-agent autonomy.

At Birdeye, our coworkers coordinate specialized agents where variability demands it, while relying on deterministic application services for permissions, database transactions, idempotency checks, and audit logging.

This separation gives us two distinct benefits. The agents stay focused on understanding intent, handling conversation, and choosing actions. The application platform guarantees that actions obey security boundaries, timeouts are handled safely, and every state mutation is recorded with full auditability.

For product and engineering teams, the starting point is one frequent customer job with a recognizable finish, available data, enforceable permissions, and failures we can observe.

From there, six steps keep the roadmap connected to customer value:

1. Map the work the customer still performs. Include copied information, spreadsheets, status checks, messages, and corrections around the product. Work outside the application still belongs in the picture.
2. Write the job description. Choose a responsibility specific enough to make a clear promise. “Reschedule an eligible appointment” gives the team something it can implement and verify.
3. Agree on the evidence of completion. Identify the authoritative records, permission boundaries, approval requirements, and conditions that need human involvement.
4. Connect the necessary capabilities. Preserve reliable components and expose missing actions through controlled interfaces. Build a workflow that can finish the job and explain its status.
5. Evaluate the inconvenient cases. Test timeouts, duplicate requests, incorrect identifiers, missing data, and failed handoffs. Compare the workflow with the existing process, including the attention each requires from people.
6. Expand with evidence. Delegate more actions and support more cases as observed performance justifies it. Keep unresolved exceptions visible so the team knows where to improve next.

Features still emerge from this process. Each one earns its place by helping the product complete a customer job more reliably.

Customers will continue to care about trust, usability, domain expertise, and business value. Those fundamentals matter as much as the intelligence inside the product.

What changes is how much work they can reasonably expect software to take on.

If a customer can delegate a job and receive a dependable result, a product that still requires them to coordinate every step has a harder value proposition to defend. Adding features will not automatically close that gap.

This is why I believe in the AI coworker direction we are taking at Birdeye. Our coworkers bring agents and software capabilities together around the business work customers need to complete.

As an engineering leader, I care about turning that direction into a product people can trust. The standard needs to be clear: a defined job, the context and authority to act, evidence of completion, and a useful path back to a person when judgment is needed.

I still like building features. I want every feature to move us closer to that standard.

The question I want our products to answer is simple: what can the customer now delegate, and how will they know it is done?

That is how I want us to compete: through the work our software can reliably carry through for customers. It is the shift from AI in SaaS to SaaS in AI, and it is why I am committed to building around AI coworkers and customer outcomes.

What is the difference between AI in SaaS and SaaS in AI?

In the distinction I use here, AI in SaaS adds intelligence to a workflow the customer largely coordinates. SaaS in AI organizes software capabilities around an AI execution layer that carries out a defined task, checks the result, and involves people when needed. A product can support both patterns.

What is an AI coworker?

An AI coworker takes on a defined business job, using the context, permissions, agents, and software capabilities needed to carry it through. At Birdeye, our coworkers bring this approach to marketing, operations, and customer experience. People set the operating boundaries and retain control over decisions that need their judgment.

How is an AI coworker different from an AI agent?

I use AI coworker for the role the product takes on for the customer, and AI agent for a technical component that can choose and perform actions. A coworker can coordinate multiple agents, application logic, and human decisions around a job. The architecture depends on the responsibility being delegated.

What is outcome-based SaaS?

Outcome-based SaaS takes responsibility for a defined customer task and measures whether the agreed result occurred. A correctly rescheduled appointment is an operational outcome. Wider benefits, such as attendance or revenue growth, require separate measurement and attribution.

How do you measure an AI coworker's success?

Measure the share of incoming work it can handle, how often tasks finish correctly, time to completion, and the human review or repair still required. Verify results against the actual system records and track exceptions separately. Wider business impact needs its own baseline and measurement.