Want AI Agents to Run a Profitable Business? Six Infrastructure Bottlenecks Users Are Hitting

As AI agent capabilities iterate rapidly, a practical question has surfaced: when tasks move from demos to real business operations, how much mess do humans still have to clean up for agents? On Reddit, a developer building an agent payment solution started a discussion, inviting those who have actually tried to use agents to build businesses, sell services, and generate revenue to share the bottlenecks they've hit in operations.

1. Running a Business with Agents Gets Stuck at "Digital Identity"

The top pain point in the discussion is the account and identity system. Registering a "genuinely usable" Google account or business email for an agent is far more complicated than imagined. Phone number verification, backup email, terms acceptance, and other steps in the registration process often require human intervention. Even more troublesome is maintaining persistent login—after a session expires, the agent cannot re-authenticate on its own and can only wait for a human to take over. According to the post, some users have to manually log in again every day just so the agent can continue working.

This exposes a structural contradiction: the identity verification mechanisms of mainstream internet services are designed for "human operators." CAPTCHAs, device fingerprints, anomalous login detection, and other anti-automation measures precisely form the first wall blocking agent operation.

2. Commercial Platform Access: Doors Agents Can't Get Through

Obtaining access to commercial platforms such as Google Ads and Meta is the second high-frequency blocker. Ad account activation, payment method binding, and business qualification review on these platforms usually involve multiple rounds of manual review and identity verification. Even if an agent can complete registration forms, the subsequent account approval process may still be stuck for days.

The post mentions a typical scenario: the agent stalls while waiting for an email verification link or 2FA code, until a human manually copies and pastes the code in. This "second-level interruption" seems minor, yet it completely breaks the agent's autonomous operating chain.

The automation dilemma of 2FA and CAPTCHAs: Two-factor authentication relies on TOTP dynamic codes, SMS verification codes, or hardware keys, and its security premise is precisely that "only a real person holding the second device can complete it." TOTP can technically be computed by the agent itself (the shared secret is programmable), but SMS and email verification codes must be read and forwarded by a human, while behavioral verification such as reCAPTCHA and hCaptcha relies on human-characteristic signals such as mouse trajectories and browser fingerprints. This forces the agent into a suspended "waiting for human" state at critical nodes, and is also the hardest conflict to reconcile between platform anti-automation strategies and agent autonomy.

3. Payments and Subscriptions: The Boundaries of an Agent's Financial Authority

Paying for tools, subscriptions, hosting services, or ad placements is a hard requirement for agents running a business. But the vast majority of current payment systems were not designed for the scenario of "payments initiated by agents." Credit card information custody, 3D Secure verification, subscription renewal confirmation, and other steps all require a human to be present.

The developer who started the discussion is himself building a payment solution for agents, and this is precisely the motivation. However, the post also admits that some operations should legitimately retain human approval—the problem is that "already approved tasks" are interrupted by meaningless repeated authentication.

3D Secure and agent payment authorization: 3D Secure (such as Verified by Visa) requires the cardholder to be redirected to the issuing bank's page during a transaction to complete SMS OTP or biometric verification. It is essentially an anti-fraud mechanism designed for "card-present, person-present" scenarios, and agents cannot pass it independently. To bypass this limitation, the industry has produced solutions such as virtual card numbers, per-transaction limit tokens, merchant whitelists, as well as OAuth-based restricted payment authorization (where the user pre-authorizes the agent to charge within a quota and merchant scope). This kind of fine-grained authorization is exactly the crux of what the original text calls "approved tasks still being repeatedly authenticated"—authorization should be bound to the task rather than to each transaction.

4. The Mire of Services Without APIs and Failure Recovery

Connecting to services without usable APIs is another frequently mentioned challenge. A large number of SMB software products and industry platforms still only provide web interfaces, so agents can only simulate operations through browser automation, whose stability is naturally lower than API calls. Once the page structure changes or anti-scraping mechanisms are triggered, the task fails.

Failure recovery involves state management: after an agent fails at a certain step, how can it continue from the breakpoint without repeating completed work? The post specifically points out that re-executing already successful steps not only wastes resources but may also cause side effects (such as duplicate orders or duplicate emails). Reliable rollback and checkpoint mechanisms remain a blank area in engineering practice.

Checkpoints and idempotency: The engineering core of failure recovery is checkpoints and idempotency. Checkpoints persist the state of long tasks so that the agent can resume from the last successful step; idempotency requires that repeated execution of the same operation produces no additional side effects, usually by having the client generate an idempotency key so the server can identify duplicate requests. For API-less services that can only be automated via browser, both are difficult to achieve—web forms often have no idempotent semantics, and repeated submission means duplicate orders. Therefore, in practice the agent must maintain its own operation logs and deduplication logic, which is exactly the engineering gap referred to in the original text.

5. Which Interruptions Deserve Priority

Based on feedback in the discussion, the most annoying repetitive interruptions fall into three categories: first, re-login after session expiration; second, copying and pasting verification codes or verification links; third, reconnecting tools that were already authorized but disconnected due to token expiration. None of these involve decision-making; they purely consume human attention "to keep the agent running."

Participants generally agree that human approvals that genuinely need to be retained (such as large payments or publishing content externally) should be treated differently from these mechanical interruptions. The latter are products of missing infrastructure, not necessities of security design.

6. What Underlying Infrastructure the Agent Economy Needs

From this discussion, it is clear that for AI agents to truly take on business operations, what is missing is not just stronger model capabilities, but a whole set of identity, payment, and permission infrastructure designed for non-human operators. Agent-friendly account systems, fine-grained control of payment authorization, standardized access to API-less services, and persistent management of task state—these areas currently operate in silos and lack unified protocols.

The initiator explicitly states that his team is exploring peripheral infrastructure beyond payments and hopes to identify which repetitive blockers are worth investing in solving. This also points to a direction: the next wave of opportunities in the agent economy may not lie in the model layer, but in the middleware layer that lets agents "legally and smoothly exist on the existing internet."

For practitioners currently attempting agent operations, this stage still requires a great deal of "babysitting" work. But the consensus revealed in the discussion is clear: those purely login-, verification-, and reconnection-type interruptions are the parts with the least value to preserve and the ones most in need of being swallowed by infrastructure.

Background Supplement

Session maintenance and token mechanisms: The login state of web services is usually carried by cookies or OAuth access tokens, the latter of which are further divided into short-lived access tokens and long-lived refresh tokens. A well-designed client will silently exchange a refresh token for a new token after the access token expires, but most consumer-facing services do not open this path to automated clients, or directly revoke the refresh token when detecting non-browser fingerprints or anomalous IPs. Agents cannot, like humans, re-enter passwords in a pop-up and complete secondary verification, so "token expiration → manual re-login" becomes a fixed loop.