When to use this note: you want to understand how agent companies build, consider an agent startup, or examine agent business models. The original collection organizes about 76 Shensiquan case articles into horizontal agents, vertical agents, infrastructure and business models.
The original organizing thesis: Cursor combines training, its product environment, microVMs and reinforcement learning; Anthropic's discussion shifts attention from intelligence to permission; Imbue illustrates general-agent investment; and sales, support, recruiting, law, healthcare, insurance, HR and financial/data work illustrate vertical opportunities.
Historical evidence notice. Company valuations, funding, revenue, adoption, performance and forecasts in the early sections are claims or headlines in the archived collection, not current facts independently checked for this translation. A translated headline does not endorse its claim. Later additions distinguish interpretation from verification more explicitly.
0. Four broad agent-company types
| Type | Examples in the collection | Approximate mentions |
|---|---|---|
| Horizontal/general agents | Imbue, Manus, Devin, OpenAI Operator | 10+ |
| Coding agents | Cursor, Lovable, Devin, Replit, Codex | 15+ |
| Vertical agents: sales, support, recruiting, law, healthcare | Harvey, 11x, Eve, Decagon | 30+ |
| Agent infrastructure | LangChain, GitHub Spec Kit, insurance, memory, browsers | 15+ |
1. Cursor: “training is the product”
This section follows the archived November 2025 Cursor account.
1.1 The central claim
The collection attributes to Cursor AI researcher Sasha Rush at Ray Summit 2025 the claim that Composer approaches top frontier-model quality while generating tokens four times as efficiently. The intended product benefit is speed that preserves flow, with an example of a response in two seconds. These are reported internal claims, not a benchmark reproduced here.
1.2 Three technical challenges
| Challenge | Approach described |
|---|---|
| Match training and inference | Thousands of GPUs, mixture of experts, microscaling FP8 and custom kernels; a reported 3.5× Blackwell improvement |
| Very long rollouts | 100,000–1,000,000 tokens and hundreds of tool calls; a single Ray controller handles stragglers |
| Keep training aligned with production | Use the same cloud-agent microVM environment for training and the product |
1.3 A key design decision
The reported arrangement uses the same agent-server environment for cloud-agent operation and reinforcement learning. The model therefore learns to operate in the product's actual setting during training, rather than being adapted to it only afterward.
1.4 Cursor as described in the Q1 2026 archive
The historical note lists a reported $50 billion valuation, a March 2026 Kimi promotion as a multi-model-routing example, an interview with its lead designer about AI-native design, and an account of Cursor, Perplexity and Lovable choosing an “anti-framework” approach. These entries describe the archived coverage, not a current company profile.
2. Anthropic: permission as an AI moat
This section follows the archived May 2026 account of Jaya Gupta's argument.
2.1 The central distinction
Gupta's reported thesis is that enterprise AI's scarce resource is moving from intelligence toward permission.
- Adviser: supplies recommendations.
- Operator: takes action—writes code, merges PRs, opens or closes tickets, changes production configuration, sends messages or triggers downstream systems.
Before that boundary the model is an assistant; after it, the model becomes part of the operating system of the organization.
2.2 Permission means organizational trust, beyond IAM and SSO
The relevant question is whether legal, risk and board-level decision makers will authorize a model to act in real systems. Identity and sign-on mechanisms alone do not establish that trust.
2.3 The historical playbook: sell capability and governance together
The note uses four analogies:
- Google changes a control layer, illustrated by Privacy Sandbox.
- Microsoft occupies the identity layer, illustrated by Entra ID and Security Copilot.
- AWS sells infrastructure with safeguards.
- Palantir binds deeply into operational settings, raising replacement difficulty.
2.4 Two proposed differences for AI
- Capability can also create risk: improving a model's ability to fix vulnerabilities may improve its ability to exploit them. The archive attributes this warning to Anthropic's model-release discussion.
- Repeated use may build organizational context. Unlike a simple infrastructure subscription, replacement may require reconstructing accumulated knowledge about the company. This is the author's argument, not proof of an unavoidable switching barrier.
2.5 Other Anthropic coverage in the collection
| Archived headline or topic | Angle |
|---|---|
| “Forty-plus people driving 130 billion in revenue” | A self-growing black-box narrative; currency and measurement are not established by the headline |
| Sixty-nine Anthropic employees using AI in businesses | Internal use/dogfooding |
| Valuation doubling in three months and exceeding OpenAI | Investor and eventual-listing narrative |
| Entering finance | Verticalization |
| A 2025 talent report claiming 80% retention | Talent competition |
| One person replacing a marketing department | AI-assisted marketing narrative |
| Why agents fail to reach production | Agent engineering |
| Claude Code's wider ambition | Skills and an operating-system strategy |
These are topics and claims in the historical reading list, not newly verified financial or corporate findings.
3. General and horizontal agent companies
3.1 Imbue
The cited Shensiquan headline describes a $1 billion valuation and $200 million financing for a next stage of agents.
3.2 Manus
The collection treats Manus as a Chinese company's international expansion case. The related newtype agent-architecture note discusses its vulnerabilities and positioning.
3.3 Devin / Cognition
The note groups Cursor, Devin and Claude Code as prominent coding-agent examples and includes coverage of another fast-growing entrant after them. This describes the collection's framing rather than a definitive current market ranking.
3.4 Operator and computer use
OpenAI and Anthropic illustrate computer-use approaches. A cited a16z prediction says agents may work like people and exceed human efficiency within eighteen months; this remains a forecast.
3.5 A browser-agent operating system
An archived article describes a $22 million Accel-led round and interest among YC founders. It concerns a browser-agent “operating system,” distinct from the multi-account browser arrangements in the overseas-marketing and Wang Kai agent-matrix notes.
4. Three business-model patterns
4.1 “Agents end the era of X”
| Archived case | Incumbent/category targeted | Pitch in the coverage |
|---|---|---|
| A “Claude Code for sales,” with a reported $35 million Peter Thiel investment | Salesforce | End the Salesforce era |
| AI-native ERP, with a reported $25 million Sequoia US round | Traditional finance software | Replace existing financial software |
| AI rebuilding law firms, backed in the account by Sequoia US | Legal SaaS that sells tools | Rebuild the service directly, rather than sell another tool |
4.2 Infrastructure built for agents
| Archived example | Role |
|---|---|
| Agent insurance, reported $15 million | Who pays when an agent makes a mistake? |
| Git for the agent era, associated with a former GitHub founder and a reported $17 million a16z round | Version control for collaboration |
| Agent email, reported $6 million from YC | An email identity for an agent |
| A 2025 AI-memory-system comparison | Memory infrastructure |
4.3 Agents with subscriptions
The reading list includes an iMessage personal assistant with two-step setup and a $49 monthly price, a highly specialized AI sales-training company with a reported $50 million round, and a former AppSumo CEO's argument that founders must move from building engines to designing engines. Prices and rounds are historical source claims.
5. A failure case: 11x
The early collection records controversy and substantial customer churn around the AI sales/SDR company 11x in 2024–2025. A later headline describes another digital-employee company raising $25 million after that controversy.
The original note's interpretation is that automating sales-development tasks alone is insufficient; organizational trust and permission also matter. This is a lesson drawn from the coverage, not a new investigation of 11x. The later June addition preserves a separate, more positive reported operating example without erasing the earlier dispute.
6. Eight vertical markets
See the related Shensi AI B2B verticals note for the detailed cases. Figures below reproduce the historical list, not independently verified current rounds.
| Market | Cases or figures in the collection |
|---|---|
| Sales | A $50 million Sequoia-backed Salesforce alternative; a $35 million Peter Thiel case; a 23-year-old founder's “zero to 800 million” headline, whose metric is not clarified here |
| Customer support | A Chinese-founded $200 million case at a reported $1.5 billion valuation; another $50 million round; a $21 million Danish case |
| Recruiting | A $50 million integrated product; a $20 million case claiming 50,000 users in six months; a service used by Inflection and Anthropic |
| Legal | Harvey-like products; a 25-year-old former esports player's “700 million” headline, without a clarified metric here; Draftwise's reported $20 million |
| Healthcare | A $24 million copilot; a $42 million family-doctor case; Shimmer's reported $2.2 million |
| Insurance | A reported $30 million over six months; $15 million in agent insurance |
| HR | A reported $15 million AI generalist and vertical model |
| Finance | A reported $43.5 million case led by former Google/Meta scientists; $50 million for next-generation infrastructure |
7. Engineering practice in the Shensi collection
7.1 Training as product development
Cursor's example in section 1 aligns the production environment with training so learned tool use transfers directly.
7.2 The anti-framework approach
An archived account of Cursor, Perplexity and Lovable argues for writing lower-level systems rather than relying on general frameworks such as LangChain, AutoGen or CrewAI, seeking control and speed. This is the article's design argument, not a universal framework ranking.
7.3 Reaching production
The Anthropic production-engineering article discusses permission, context, error handling and monitoring. The historical note points readers to the original archive for details.
7.4 Sales and marketing practice
The collection also includes an account of the LangChain team's use of AI agents for sales and marketing.
8. Reading paths by goal
| Goal | Main case | Starting point |
|---|---|---|
| Build a coding agent | Cursor's training/product alignment and microVMs | RL, custom kernels and cloud agents |
| Understand an AI moat | Jaya Gupta's Anthropic discussion | Permission and organizational trust |
| Build a vertical agent | The eight-market overview | Sales, support, recruiting, law and healthcare |
| Build agent infrastructure | Section 4.2 | Insurance, Git, email and memory |
| Avoid a failure like the 11x account | Section 5 | Address trust and permission as well as task automation |
| Explore an anti-framework design | Section 7.2 | Understand direct implementation rather than assuming LangChain is required |
The collection's recurring principles are training/product alignment; permission alongside intelligence; vertical opportunity interpreted through organizational trust; capability as both benefit and risk; and data/context accumulated through use. Its “unicorns in every vertical” language is an organizing investment narrative, not evidence that any particular new venture will succeed.
9. Reference collection
The Shensi author overview is the collection entry point. The original archive contains roughly 76 articles mentioning Agent, Cursor or Anthropic. Related notes cover integrated agent architecture, newtype's Manus/Profile perspective, the January 2026 architecture research report, Wang Kai's Chrome-MCP practice, coding-agent companies and B2B verticals. Publicly resolvable source and related-note links are retained in the reference list accompanying this edition.
June 2026 addition: vertical workflow defenses and agent commercial infrastructure
This section follows full reading of two Chinese Shensi/SenseAI interpretations dated June 1 and June 5. One recounts a16z's Joe Schmidt IV; the other interprets Stripe's Emily Sands. Both are secondary accounts and author analysis. Company status, metrics and availability were not independently checked. Additional image-caption text was preserved separately without replacing the old archive.
1. Combining general connectors is not a vertical business system
Schmidt's “yellow brick road” metaphor describes products that directly overlap model providers: combine a general model, standard Drive/Slack/CRM connectors and a coordination layer. If customers need only one retrieval and can judge the answer themselves, packaging alone may offer little enduring difference.
Legal review, insurance underwriting and complex sales involve multiple systems, multiple approvers, legacy software and explicit error costs. The advantage may lie in engineering and governance deep inside the business rather than the next model. Three tests help assess an opportunity:
- Steps: one or two general calls, or reliable completion of multiple roles and stages?
- System: does the customer rely on you to coordinate the whole job, or use you as a temporary add-on? A high contract value is a clue, not proof of irreplaceability.
- Business result: are you judged on model leaderboards or on qualified leads, risk detection and contract processing? The latter connects capability with a reason to pay.
2. Four defenses must be realized operationally
| Defense | What must actually accumulate | What it does not automatically mean |
|---|---|---|
| Data feedback | Escalation rules, exceptions, human rewrites and their reasons | Logs automatically confer data rights or a moat |
| Model management | Cross-provider selection, upgrade regression tests, prompts and customer edge cases | A generic router cannot be copied |
| Cost control | Frontier models for hard work, cheaper options for routine tasks, small models only after narrow validation | Using the most expensive model everywhere preserves margin |
| Governance | Who may authorize, permitted actions, actual actions and responsibility for failures | Writing “compliance” satisfies an industry's requirements |
FurtherAI's insurance example treats workflow as operational memory. Similar intake, review, quotation and underwriting stages hide company-specific risk weights and rules for conflicts. Deterministic software handles repeatable steps, agents handle variation and exceptions, and accountable judgments remain with people. Escalations and rewrites feed later rule improvements.
The 11x sales example separates prospect selection, enrichment, account research, CRM context, copy, qualification and delivery. Its CEO says roughly half the steps are deterministic ranking, filtering or querying, and reports a fourfold increase in positive replies over several months. This is a case claim, not a universal ratio, and does not erase section 5's earlier controversy. Ask which stage really needs a model, which needs stable rules and who maintains it as feedback changes.
3. Separate payment responsibilities when agents become buyers
The Stripe interpretation treats agents as participants buying services, deploying applications and consuming compute. The following is a June 2026 product narrative, not a current integration guide.
| Component | Responsibility described | Boundary to preserve |
|---|---|---|
| MPP, a machine-payment protocol | Program-readable prices and payment flows in place of human checkout pages | Automatic execution still stays within prior authorization |
| Link wallet | Authorized agent spending without directly exposing credentials; traceable purchase notifications | Notification does not imply either a manual click for every purchase or unlimited authority |
| Stripe Projects | Manage deployment-related services through a CLI | Fewer screens do not remove account and permission review |
| Metronome and Tempo | Coordinate usage measurement and settlement, exploring charging as consumption occurs | Correct metering, successful collection and valid authority are different questions |
| Radar | Detect trial abuse and nonpayment after consumption | The article does not establish that a category of fraud has been solved |
4. Design cost, billing and risk together
Using Lovable and ElevenLabs, the article describes starting with simple subscriptions and later combining included usage with overage charges. AI costs rise with use. Subscription revenue alone is insufficient without understanding heavy-user consumption. Usage-based billing requires meaningful units that can be defined and tracked.
Free trials also cost money: false accounts may consume capacity and disappear. Pure prepayment can interrupt legitimate customers; end-of-month billing increases bad-debt exposure. The article's streaming-payment proposal tries to shorten the interval between consumption and collection. It is an option to assess, not proof that stablecoins solve every problem.
Two issues remain unresolved: data rights, feedback scale and competitors' shortcuts affect the durability of vertical defenses; the article does not explain how an ephemeral agent inherits a credit history and accountable legal actor. Treat these as validation questions, rather than assuming that a complete commercial diagram proves an operating business.
October 8, 2026 addition: remove temporary steps after model upgrades; retain goals, permissions and acceptance criteria
Based on Shensiquan's October 7 Chinese interpretation of an interview with Tibo. It combines interview reporting, media reporting and the author's interpretation. The original program, images and current product state were not independently verified in this review. This addition extracts design methods; connector counts, subscription coverage, speed multipliers and price ratios are not used as selection evidence.
Separate two types of workflow steps
Some steps compensate for a model's limitations at a particular time, such as repeated reminders or manual decomposition of a task the model could eventually handle at once. Others express necessary business conditions: required results, accessible data and who may approve publication. Re-test and simplify the first group as capabilities improve; retain explicit conditions in the second.
Rationale. The reported interview describes agent teams expanding and contracting as capabilities change. The transferable lesson is not that a single agent always beats multiple agents. Temporary workarounds should not become permanent product requirements by default. Compare each upgrade on the same real tasks, measuring quality, human intervention and cost. Restore the previous arrangement if simplification hurts results. Remove steps because of task evidence, not merely a model announcement.
Design proactive reminders and proactive changes separately
The production incident in the article describes an agent connecting timing, activity and a service anomaly, then asking the owner for permission to repair it. The owner did not permit direct action. This account can inspire reminders; it does not establish reliable autonomous production repair.
Separate detection, impact explanation, proposal preparation and execution, with distinct permissions and result records. Show users why something matters now, which task is affected and what action is proposed before execution. Timely reminders do not confer permission to change code, send messages or purchase services. Evaluate missed alerts, false alarms, interruptions and unauthorized actions together.
Less configuration still requires inspection and correction
Hiding model selection and loop configuration can reduce learning effort, but the platform then owns those decisions. Users should understand the objective, information used and actions already taken, and know how to change the objective, stop subsequent actions and revoke permissions. Otherwise complexity has merely become invisible.
Monitoring is a continuing cost. If another system must check agents for anomalies and intercept risks, include that work in the total cost per successful task. A model call's price does not represent the whole service. A warning, a paused task and an external effect already produced are different states. Stopping further execution does not automatically reverse earlier actions.
Keep distribution claims as questions to verify
The article reports possible emphasis on retention and usage quality in plugin recommendations, alongside spoken claims about revenue sharing and platform scale. Without complete rules and primary verification, these are not a guaranteed acquisition channel. First test repeat demand, stable results and clear authorization. Whether the platform recommends the product, how much exposure it delivers and whether exposure converts to payment require separate evidence.
Source: Article used for this addition.
October 13, 2026 addition: define launch blockers, then check the complete experience
This section draws only product-review methods from Shensi's Chinese account of an interview with the Muse team. The original interview, team size, growth rankings and corporate transactions have not been independently verified here; this section does not assess Muse's actual performance.
Tie “not ready to launch” to a specific user task
An impressive demonstration does not establish reliable performance in everyday use. Break the intended user tasks into observable behaviors and distinguish two types of criteria before testing: conditions that must be met before launch, and aspects of the experience that can continue to improve. Every requirement in the first group must be satisfied; strong performance elsewhere cannot compensate for a failed requirement.
For example, an assistant may organize meeting action items well but mistakenly send a draft to an unconfirmed recipient. Even with excellent speed and interface design, recipient selection and confirmation may remain launch blockers. This is an editorial application example, not a tested case reported by the source. A checklist should specify the triggering conditions, expected result and failure behavior, rather than subjective labels such as “useful” or “intelligent.”
Recheck each iteration under the same conditions to identify what a change fixed and whether it broke something that previously passed. When to use this: before moving from a prototype to real-user trials, replacing a model or adding actions the assistant can execute. Counterexamples: lowering thresholds at the last minute to make every row appear to pass, or treating every minor imperfection as a blocker so that launch has no clear conditions. The consequences of user tasks and the product's commitments should determine how requirements are classified.
Check whether the features fulfill the same promise
Features can each work in isolation yet create a confusing combined experience. In addition to checking individual requirements, walk through a complete real task to test whether the goal, interface feedback, executable actions and human confirmation are consistent. If one feature increases automation while another makes it impossible for users to tell what has already happened, the team needs to reconsider that tradeoff.
A coherent experience requires explicit product judgment and someone accountable for decisions. It does not mean every suggestion belongs in the release or that small teams automatically build better products. The source's observation about a single point of view can help identify conflicts between features; team size and a leader's taste cannot replace user validation. For the related enterprise questions of evaluation and delivery responsibility, see Agent-native products and enterprise AI.
Source: Shensi: Why did the Muse team build what it describes as the fastest-growing AI product since ChatGPT?. The growth ranking in the source title is a source claim, not a verified fact adopted by this section.
October 15, 2026 update: Decide how personal context can be used before choosing local or cloud execution
Evidence scope: The full Shensi article on why Perplexity is betting on small businesses and local compute. It combines a retelling of an interview with the author's analysis; the original program was not independently checked for this update. Hardware prices, profits, future inference costs, and growth forecasts are not conclusions of this section.
Execution location and data permissions are separate decisions. A personal assistant may need files, usage habits, and long-term work context. Before choosing local or cloud execution, specify who owns the material, what the current task may read, and what information will leave the device. Running a model locally does not entitle it to read all personal information. Sending a task to the cloud does not mean the service already has complete context or ongoing access rights.
Which costs can local compute reduce? The article discusses using local compute for ongoing work and calling different capabilities as tasks require. Local execution may reduce recurring cloud inference bills, but it still requires device resources, maintenance, and recovery. Cloud services offer other capabilities and operating arrangements, with network dependencies, data transfer, and recurring charges of their own. The two locations can share work; being local does not by itself establish that a system is cheaper, safer, or more effective.
Editorial application: Compare the same task. Hold the input material and completion criteria constant. Check whether each approach produces the correct result, whether the user can see which data is being used, who restores service after a failure, and the total cost of ongoing operation. If a device is unavailable, context is missing, or an action needs approval, make the waiting state explicit. Requiring extensive prompting and troubleshooting from users is also a product delivery cost. The earlier discussion of model routing still applies; see enterprise AI delivery responsibilities for operational ownership. This section adds the boundaries around context location and execution responsibilities.
Source: Shensi: Why Perplexity is betting on small businesses and local compute.
Addition: Check personal-agent data use at every service
This addition draws on a Chinese report about Persona collected on October 12. The report mixes company statements, media accounts and the author's interpretation. Product terms, certifications and downstream contracts have not been independently verified. The following are review questions, not findings about Persona's current practices.
A promise not to train an in-house model does not explain the full data chain
The existing article discusses personal context, deployment location and permissions. This addition examines where data goes after entering the product. The entry service, its persistent memory, third-party models and transaction services may have different responsibilities. A company's promise not to train its own models does not establish downstream providers' retention or training policies. One chat interface does not imply one data processor.
For each data flow, record the recipient, purpose, retention period and deletion mechanism. Using an email to draft a reply and deriving a lasting preference from it are different purposes. Deleting a conversation also raises questions about derived memories and data already passed downstream. Where terms or evidence of actual controls are unavailable, leave the point unverified instead of filling the gap with a general privacy promise.
Review incentives and transaction authority separately
The report discusses a design combining advertised products with neutral recommendations. Saying that the model does not know which products are advertisements describes only one part of the process. Candidate selection, ranking criteria and the effect of commercial agreements on presentation still need explanation. One proposed test is to compare recommendation reasons and candidate coverage for the same request and check whether commercial content is identifiable. This is an editorial testing proposal; no such experiment was performed on the product.
A recommendation matching a user's preferences and an authorized purchase are separate conditions. Review the product rationale, price and payee, action confirmation and failure handling separately. Permission to read an inbox must not be expanded into permission to pay. The source's broad statements about legal liability were not verified and are not presented as general legal conclusions.
Use this review when evaluating personal assistants with persistent memory, multiple model services or commercial recommendations. Map the actual data route before deciding what to share. If only marketing material is available, retain the open questions; financing and founder credentials do not replace verification.
Addition — October 20, 2026: Give topic chats a task lifecycle
Evidence scope: the October 20 Builders digest’s account of Nikunj Kothari’s personal experience with Wabi 2.0. This is one user’s description, not a product test or retention experiment, and it cannot represent other users. The acceptance checks below are editorial suggestions drawn from the case.
Keep a continuous main entry point while allowing individual tasks to end
A personal agent need not put every activity into one indefinitely growing conversation, or create a permanent new character for every task. A main agent can coordinate work while purpose-specific topic chats handle a trip, a tax year, or a period of school-related activity. Archiving a conversation when its task ends lets the active workspace reflect what still needs attention, reducing the effort spent finding and managing chats.
In Nikunj’s example, Wabi noticed a flight and created a New York trip chat, then archived it after the trip. His 2025 taxes followed a similar pattern. A school-related chat could be shared with his wife. The reusable product idea is organizing context around a specific activity and allowing that activity to end. His greater interest in the new version is a personal experience, not evidence that this design generally improves retention.
Sharing a task need not mean sharing the entire assistant
Sharing can be scoped to a particular topic conversation rather than all of the main agent’s memories. Our suggestion is to design chat creation, ongoing reminders, sharing, and archiving as separate decisions. Users should understand who can see which context, whether proactive reminders stop when a task ends, how archived material can be retrieved, and which information the main agent will continue to use. In this case, archiving means putting a conversation away; it does not establish that the product deletes its data or revokes permissions.
Counterexample and acceptance checks. Nikunj also finds the product too proactive, showing how automatic chat creation can itself add management work. Start by checking one trip: does the system recognize its beginning and end correctly, are reminders useful, is sharing restricted to the selected activity, and can the user easily correct or revoke it? Do not count only the chats created; also observe mistaken creation, interruptions, and the time users spend organizing conversations. Relationships requiring a stable identity and genuinely ongoing projects should not be forced to end merely to make an interface look tidy.
Source: https://x.com/nikunj/status/2112219327881761008
October 21, 2026 addition: consumer-agent positioning depends on who pays and whose interests it serves
Wang Kai proposes a product hypothesis: personal and vertical agents may differ not only by task but also by membership or advertising models, service preferences, safety priorities, price sensitivity and supply-chain organization, much as consumer channels do. His examples include a paid concierge, ad-supported services, agents emphasizing safety or low prices, and unified memberships around local services. These are his hypotheses, rather than verified product terms or market outcomes.
Useful comparison questions are who pays, whose interests recommendations or rankings optimize for, whether users understand commercial relationships and whether the promised service can be delivered consistently. Membership does not automatically ensure an ad-free or neutral service, and free access does not automatically imply misaligned interests. Terms and actual behavior still need checking. A supply network or membership system can be a service hypothesis; access to supply, quality control and fulfillment cannot be inferred from an agent interface.
This adds the observation that the same task can support different commercial orientations, alongside permissions, proactive assistance and task acceptance. Predictions about lower entry barriers and limited monopolization are not adopted as market conclusions.