A small-business owner usually reaches Meta to find customers. Muse gives Meta a chance to become the place that owner goes to decide what to do next: which campaign to prepare, which expense to investigate, which customer needs a reply. That is a more valuable position than producing another piece of marketing copy.
On September 29, Meta announced Muse for Small Business, adding business-focused skills and connections to its existing agent. The useful distinction is between two opportunities that can look identical in a partner-logo grid: using an agent to operate your business, and making your business available to somebody else’s agent. Success at one does not establish success at the other.
RohitAI’s read: Meta is competing for the starting point of business work. SaaS vendors could gain usage through Muse while surrendering the screen where customers choose their next action. Owners could save administrative time—or spend it reviewing an expanding queue of suggestions. The outcome depends on what gets completed and accepted, not how many services connect.
This extends our July Muse Spark API analysis. Then, the question was what developers could build with Meta’s intelligence. Now, it is what happens when developers bring their products inside Meta’s agent.
September 29 expands the business brief, not the platform’s birth date
There is an important chronology correction. Muse launched as a personal agent on September 8. Meta’s September 24 developer recap already described the Muse Connector Platform as launched. Today’s announcement expands the SMB proposition; it is not the first opening of that platform.
Muse is a persistent agent, not simply a chat window: Meta’s original launch description puts it on a dedicated cloud computer with a browser, able to keep working after the app closes. That persistence is useful for unfinished business tasks, but it also makes permissions and handover part of the product decision.
The SMB announcement describes availability in the US and Canada and names Instagram professional analytics, Facebook Pages and Meta ad accounts. Third-party integrations include Asana, Box, Canva, Dropbox, Figma, Granola, HighLevel, Intuit QuickBooks, Klaviyo, Lovable, Notion, Shopify, Slack, Stripe and Zoom.
Its examples span growth planning, campaign drafting, inbox and calendar triage, expense review, and drafted responses. Meta says publishing, sending and spending require approval. These are stated capabilities and illustrative workflows, not an independent measurement of hours saved.
A founder should read that list as a reason to investigate a workflow, not as an endpoint specification. The announcement does not establish which objects every connector can read, which writes every account can authorize, or whether an entire cross-app task will work for a particular customer. Check the actual account before promising a deployment.
Confirmed change: more business-focused work inside the existing Muse agent.
Strategic possibility: operational software becomes reachable without being the customer’s starting screen.
Still unproven: sustained time savings, incremental sales and dependable completion across a real business’s messy records.
One connector ecosystem, two different businesses
Imagine a bakery. Its owner asks Muse to prepare a weekend promotion using current products and past campaign results. Separately, a customer asks their own agent to find a birthday cake available for Saturday pickup. Both tasks could involve the same bakery software. They have different principals, permissions and definitions of success.
The first agent works for the owner. A useful result might be an unpublished campaign with accurate stock information. The second works for the customer. A useful result might be an accepted order at the promised price and pickup time. Generating the first artifact does not prove the bakery acquired the second customer.
Here is the decision framework I would use before commissioning an integration. These are proposed product boundaries, not claims about Muse’s implementation.
Business role | Useful first outcome | What to measure |
|---|---|---|
Owner using Muse | A checked expense packet or campaign draft | Net owner time saved after review and corrections |
Merchant serving customers’ agents | An order the business can actually fulfill | Incremental contribution after cancellations, returns and support |
SaaS vendor supplying a connector | A valid operation in the customer’s source system | Accepted operations per connected account, including repair costs |
This split changes the roadmap. An owner-side integration needs the business’s internal context. A customer-facing service needs dependable availability, prices and purchase rules without exposing internal records. A connector built for one should not quietly inherit the authority of the other.
An agent can save your staff time without bringing you a single new customer. It can also bring you an order without running your business.
The commercial question is therefore two questions: who pays for the work, and who benefits from the transaction? Keep those answers separate before estimating a market or deciding what to build.
Your product can become more useful while its dashboard gets quieter
For an SMB software vendor, the uncomfortable possibility is not immediate replacement. It is becoming essential infrastructure that customers no longer visit as often.
Consider an accounting product. An agent can ask why expenses rose and present an explanation. The underlying system still has to distinguish a pending transaction from a posted one, associate it with the correct business, and preserve the accepted record. Conversation and accounting truth are different responsibilities.
That distinction is visible in Plaid’s Muse integration, which supplies financial context such as balances, transactions, investment holdings and mortgage information. Access to that context does not establish authority to transfer money, nor does it prove that an agent’s accounting interpretation is correct.
My expectation is that successful SaaS connectors will expose small, verifiable actions rather than reproduce an entire dashboard in chat. “Prepare an expense review with source links” is a clearer contract than “manage my finances.” A narrow action can say exactly what it used, what changed and what remains unresolved.
For vendors, this means measuring backend usefulness alongside product visits. If customers open fewer screens but complete more valid operations, declining sessions might conceal growing value. Conversely, thousands of agent calls that generate corrections are not healthy engagement. The result that survives review deserves the credit.
There is a distribution dependency here that switching model providers will not solve. The agent’s interface can influence which service gets considered and how its result is presented. Keep identifiable receipts, direct customer relationships and a usable native product. Integration should add a route to your service, not erase every other route.
We raised a related issue in our Siri app-actions analysis: software can compete through callable actions while another platform controls the interaction. That is an editorial parallel, not a claim that Apple and Muse share protocols or permissions.
Approval, discovery and payment are three separate gates
The Muse platform page describes a concrete admission process: explain the product, undergo functional, security and legal review, complete end-to-end testing, then enter the directory if approved. Featured placement receives separate editorial consideration. Submission, approval and featuring are not interchangeable milestones.
The reviewed public page supplies no review deadline or published fee and revenue-share schedule. That does not tell us what private partner agreements contain. It does mean a startup should not forecast directory-dependent revenue from a presumed approval date or an invented marketplace take rate.
Also, do not confuse Muse submission with Meta AI Connectors. The latter is separately labeled a developer preview for selected builders, with public publishing and discovery described as later phases. A similar name is not evidence of transferable approval.
Payments add another distinction. In its September 8 announcement, Stripe says US consumers can use Muse with Link at more than one million Link-accepting businesses, with purchase-scoped virtual cards elsewhere. Users approve each transaction total, and Muse does not see their underlying payment details. That merchant footprint is not a count of Muse connectors or acquired SMB customers.
Nor does payment capability settle merchant access. GeekWire reported on September 20 that Amazon had blocked Muse shopping access and objected to its participation and identification practices. That is a dated dispute, not proof of a permanent ban or a demonstrated credential breach. It illustrates why technical capability and merchant acceptance must be tested separately.
For a merchant, I would instrument the funnel below. Treat it as an evaluation model, not a promised Muse analytics feature.
Eligible customer request
→ service considered
→ useful offer returned
→ customer authorizes
→ merchant accepts
→ order fulfilled
→ contribution retained after returnsA catalogue listing establishes none of the later steps. Compare agent-originated business with a holdout or a matched baseline before calling it incremental demand. Otherwise, a new checkout route may simply receive credit for customers who would have bought anyway.
The scarce resource is the owner’s attention
The bakery owner does not need unlimited campaign drafts. They need a small number worth approving, with enough evidence to approve them quickly. An always-working agent can increase the supply of proposals faster than it increases the owner’s capacity to judge them.
Meta’s technical security explanation describes Sentinel as an independent host-side permission authority for connector actions and network egress. Grants can be one-time, session-scoped, task-scoped, time-bounded or perpetual; some previously authorized or low-risk actions can proceed without interruption. Approval therefore does not necessarily mean a new click for every action. This is documented design, not an independent enforcement audit.
My practical recommendation is to treat review time as a product budget. A useful approval should show the actual destination, recipient, content version, spending limit and duration. “Grow the bakery” is an objective. It is not an intelligible authorization for whatever actions an agent decides might help.
For example, approve one specific promotion, for one account, against a capped budget and stated dates. If the price, audience or creative changes afterward, test whether the prior approval still applies. Group related decisions when it improves comprehension, but do not silence interruptions by granting authority the owner cannot explain.
The right automation metric subtracts checking and cleanup. A faster draft can still produce a slower working day.
That gives a deployment team a useful stop condition: if review and interruption time outweigh the time saved, reduce the workflow’s scope before upgrading its autonomy. More agent activity is not the objective.
A personal agent needs a business handover plan
Persistence creates an offboarding problem. Meta’s connector help page says disconnecting stops further data exchange, but previously used information can remain in Muse’s memory and conversation history. It also says Meta does not review custom connectors. Some Meta accounts connect automatically through a shared Accounts Centre.
For a business, removing access and removing remembered context are therefore separate tasks. If a contractor connects supplier records, revoking the supplier connection does not by itself establish that the agent has forgotten those records. Tomorrow’s recommendation could still rely on yesterday’s context.
Use business-owned identities where supported, preserve authoritative records outside personal chat history, and test handover before staff depend on the workflow. The departing person should not be the only one who can explain what the agent was allowed to do or where its completed work lives.
Privacy questions need similar precision. Meta’s security documentation says VM data and conversations are not shared with its ad systems, while external browsing can indirectly influence advertising. It describes training use with an opt-out. The current Secure VM does not cryptographically prevent Meta operational access; Confidential VM remains a later-2026 plan in that document.
Those are distinct decisions: future access, retained context, training use and provider access. A reassuring answer to one does not settle the others. Review the actual settings and applicable business terms before introducing sensitive records.
The first pilot should end with a record you can inspect
I would start with one reversible workflow that already consumes owner time: an expense-anomaly packet, an unpublished campaign, or a queue of draft customer replies. Use real task shapes with test or appropriately authorized data. Set acceptance criteria before seeing the agent’s output.
For the bakery campaign, a successful draft would cite the products and stock snapshot it used, flag uncertain availability, contain no unsupported offer, and leave publication separate. A beautifully written promotion for unavailable stock fails.
The following are proposed checks for your integration and source systems, not guarantees that Muse exposes every control.
Map the actual account. Record region, connected service, required plan, business identity, readable objects and permitted actions. Test the intended customer account rather than assuming a named integration has uniform capabilities.
Make stale information visible. Change a price or stock level after the draft is prepared. The final action should re-check the authoritative value or stop for review. A cached answer needs a timestamp and a clear limit on what it can authorize.
Test authority at the point of change. Use benign records to attempt the wrong tenant, a denied destination and an expired grant. Inspect the source system afterward. An agent’s statement that it stopped is weaker evidence than no unauthorized write having occurred.
Retry a completed operation. Simulate a timeout after the service accepts the request. The service should recognize the repeated operation rather than create another order or campaign. Keep duplicate prevention and permission checks in the backend, not only in instructions to the agent.
Exercise disconnection and handover. Revoke access, invalidate outstanding authority where possible, inspect retained memory and verify which artifacts remain available to the business. Where browser and connector routes are both enabled, check both.
Count the human work. Measure preparation, review, interruptions and correction time against the existing process. Include rejected outputs when calculating completion rates, and count their review cost. Do not report only the successful examples.
I would ask the service to return a compact receipt for every accepted write. This is a suggested contract, not an official Muse schema:
Business and source-system record
Requested operation and final parameters
Source version or freshness timestamp
Authorization scope and expiry
Duplicate-prevention identifier
Accepted result, pending state, or explicit failure
Correction or cancellation routeThat receipt makes a failure diagnosable. If Muse says an order succeeded but the merchant has no accepted order, the workflow is incomplete. If the merchant accepted it but the response was lost, retry handling becomes the problem. Those cases require different repairs.
Ask the adviser when you should spend less
Meta’s position in advertising creates a useful evaluation question: can the business adviser recommend something other than more advertising? This is a conflict-of-interest test, not an allegation that Muse currently biases recommendations or violates its stated data boundaries.
Give the pilot a deliberately awkward case. The bakery has strong demand but limited Saturday capacity, low margins on the promoted item and cash tied up in inventory. Ask for a growth plan. A sensible answer might improve the offer, shift demand to another day or reduce promotion until fulfillment catches up.
Judge the recommendation against the owner’s constraints and independent sales records, not only the ad platform’s attribution. If the answer cannot consider spending less, it has not demonstrated that it understands the business goal. This test is useful regardless of which company supplies the agent.
The subscription price is only the visible part of the bill
Meta’s subscription help page lists a usage-limited free tier, Power at $20 per month with 500 million Muse tokens per week, and Maximum at $100 per month with 3 billion per week. It also warns that benefits vary by region and account and describes limited testing. Verify the terms shown during onboarding.
These are product allowances, not model-API input/output prices or a guaranteed number of completed jobs. The reviewed page does not resolve enough token-accounting detail to turn the headline allowance into a reliable per-task budget.
Cost to include | Why it belongs in the pilot |
|---|---|
Subscription and partner charges | Access may cost more than the Muse plan alone |
Setup and ongoing maintenance | Changed permissions, source fields and workflows need attention |
Owner review and interruptions | Automation can move work into checking rather than remove it |
Retries, repairs and failed outcomes | Rejected or reversed work still consumes resources |
Calculate cost per accepted outcome with those costs included, then compare it with the current process. A cheap plan can be poor value when supervision dominates. An expensive plan can be worthwhile for a bounded task that reliably removes work. The pilot should tell you which situation you have.
What would make this a durable platform shift?
My first prediction is that narrow business actions will age better than broad “run my company” promises. The strongest connectors will make current state, authorized changes and failures easy to verify. Their advantage will be operational dependability, not a longer list of verbs.
Second, some SaaS vendors may see fewer visits alongside more agent-mediated usage. Watch accepted operations, renewal behavior and support burden together. If usage grows without retention or healthy economics, the connector has not demonstrated a better business.
Third, ongoing integration work may be more valuable than initial setup. Permissions expire, staff leave, prices change and business rules evolve. Maintaining a trustworthy workflow is a recurring job even when creating the first connection becomes easy.
These are forecasts, not launch results. Evidence that would strengthen them includes repeat usage after onboarding, lower review time, reliable recovery from partial failures and genuinely incremental merchant demand. More partner logos alone would not.
Questions worth settling before you connect
Is this a new Muse model?
The September 29 release is a business-focused expansion of the agent. It does not announce a new SMB model identifier or a business-workflow benchmark. Do not borrow another Muse Spark deployment’s scores as proof of this product’s reliability.
Can an unsupported service be connected?
Meta documents custom connectors for services outside the available list. That route is not Meta review or public-directory approval. Treat a custom connection as its own implementation and permission decision.
Does directory approval guarantee customers?
No. The published process distinguishes admission from featured placement and promises no demand level. Measure whether relevant requests become fulfilled business, not simply whether the connector appears.
What should a small business try first?
One bounded, draft-heavy task with a clear reviewer and an observable finish line. Expand only after the time saved survives the review and correction bill.
Keep the customer and the accepted result in view
Muse gives Meta a credible route from helping businesses reach people to helping businesses decide and act. For owners, that could remove work scattered across disconnected tools. For software vendors, it could open a useful channel while putting another company between the product and the next customer decision.
The sensible response is neither to dismiss the agent nor to connect everything. Pick which side of the relationship you serve, expose a useful bounded action, preserve the authoritative record and measure what survives review. A connector gets you into the conversation. A result the business can trust is what keeps you there.