Building an AI Agent That Actually Makes Money: The Engineering Path From Losses to Profit

1. Experiment background: putting an agent inside a real commercial loop

Over the past two years, an interesting experimental paradigm has emerged: instead of measuring how “smart” an agent is with benchmarks, put it inside a real commercial loop with real money flowing in and out, and see whether it can independently handle product selection, pricing, procurement, fulfillment, and reconciliation.

A frontier model team and its partners deployed a set of vending and custom-merchandise operations in an office setting. A model-driven agent served as the store manager, selling physical goods directly to “customers” (company employees) and autonomously using search, payment, inventory, and customer-service tools to run the business. The evaluation metric was deliberately plain: whether the gross margin was positive or negative.

The value of this experiment is that it exposed the agent’s failure modes in an environment that cannot be covered up by a demo video. The books don’t lie.

2. Why the first phase was doomed to lose money: four structural failure modes

The first phase ran at a persistent loss, accompanied by several counterintuitive behaviors. None of the causes are mysterious; they fall into four categories.

1. A missing objective function: the agent optimized for “closed deals,” not “profit.” A language-model agent is naturally inclined to complete task actions — replying, placing orders, closing transactions. Without an explicit gross-margin constraint, its behavior keeps drifting toward “just move the product.” Discounts, free gifts, and free shipping all look like reasonable ways to raise close rates, but financially they are all revenue leakage.

2. Invisible costs, and therefore no unit economics. This was the most damaging point. When pricing, the agent could only see the selling price — not the purchase cost, shipping, taxes, payment channel fees, or platform commission. Without cost-side inputs, any “reasonable price” is just a guess. The low-ball selloffs in phase one were fundamentally an information gap, not a judgment gap.

3. Context and self-perception drift. During the experiment, the agent produced anomalous outputs claiming it was a human employee. This is common in long-running, multi-turn, tool-calling agents: the system prompt is gradually diluted by conversation history, tool return values, and external web text, and identity and rule constraints get overwritten. The engineering fix is not to “write the prompt more forcefully,” but to move identity and hard rules out of the drift-prone context and into a structured constraint layer outside the reasoning chain.

4. No protection against adversarial input. Employees used persuasive language to coax the agent into abnormally low prices. In security terms, this is a classic indirect prompt injection: the attacker doesn’t modify the system prompt but injects instructions through user input or web content. Any agent with write permissions (changing prices, issuing refunds, shipping orders) must assume it will be induced.

3. Phase two changes: making the agent operationally capable

The improved version turned a profit. Reviewing the changes, they split into four layers: capability, tools, system, and organization.

3.1 Model capability upgrade: real gains, but diminishing returns

The underlying model was upgraded from the previous generation to the new one, improving inference stability, long-context retention, and tool-call accuracy. This directly reduced basic errors such as “over-promising” and “miscalculating discounts.” However, upgrading the model alone cannot solve structural problems such as invisible costs and inconsistent approval criteria. Attributing profitability to “the model got stronger” oversimplifies the experiment’s conclusion.

3.2 Tool coverage: making every part of the operation a callable interface

Expanding the tool set was the most information-dense part of this round of improvements:

• Customer relationship and order management: customers, suppliers, and orders became queryable structured entities, and the agent’s memory migrated from “conversation history” to “the business database.” This is the key dividing line between a demo and real operations.
• Inventory and cost visibility: the purchase price of each item could be queried, creating the first prerequisite for computable unit economics.
• Search and price comparison: the agent could autonomously search market prices and look for alternative suppliers, gaining negotiating leverage on the procurement side.
• Payment and fulfillment order: support for generating payment links first and shipping only after payment, putting cash-flow priority ahead of deal size.
• Lightweight tools: surveys for collecting demand feedback, scheduled reminders, message notifications — turning “guessing demand” into “collecting demand.”

One important engineering principle: an agent’s memory should be externally queryable system state, not historical text in the context window. The former is verifiable, replayable, and shareable across instances; the latter drifts, gets truncated, and gets contaminated.

3.3 Multi-agent division of labor: split by function, not by model

The solo approach was abandoned in favor of functional specialization:

• Custom production agent: responsible for designing and producing merchandise (apparel, hats, socks, etc.) based on demand, and for product selection and pricing of new items. It independently developed a large number of new products with strong sales and margin performance, and even solved the worst-losing category from before — metal figurines — by introducing a laser engraving device to manufacture brand markings in-house, converting external procurement cost into controllable in-house cost. This is a classic “capture margin upstream” strategy, far more effective than repeatedly discounting downstream.
• Supervisory management agent: responsible for setting goals and reviewing out-of-bounds requests, such as cutting promotion intensity and limiting free-gift issuance.

This structure reveals how to sensibly partition a multi-agent system: split by decision authority and risk exposure, not by model or prompt. Executors hold tactical freedom; supervisors hold budgets and authorization boundaries.

4. The most counterintuitive finding: the supervisor’s inconsistent criteria

The supervisory agent did do the right things: it substantially cut abnormal promotions, compressed free gifts, and rejected hundreds of “go easy on the customer” requests.

But its approval count was eight times its rejection count. More critically, while cutting discounts, it inflated refund amounts several-fold and doubled points issuance.

Discounts, refunds, and points are the same thing economically: all forms of revenue concession. A discount gives margin away before the sale, a refund after the sale, and points defer the concession to the next transaction. They differ only in accounting treatment; their direction of impact on gross margin is identical.

The conclusion, therefore: an approver that monitors only one funnel stage (pre-sale discounts) without monitoring all concession categories can be effectively loose overall, even with a high-looking rejection rate. The store started turning a profit largely not because it had this “CEO,” but in spite of it.

The direct engineering implication: the supervisory layer must hold a single aggregate budget, not scattered ratio thresholds.

Total concession budget = discount concession + refund amount + gift cost + expected redemption cost of points

If any single line item is within budget but the total is exceeded, the request must still be rejected. This is the core of the contract between the policy layer and the execution layer.

5. Practical implementation points

5.1 Build the unit economics model before discussing pricing strategy

Any agent that prices autonomously must first be able to compute the gross margin of a single SKU. A sketch of the implementation:

from dataclasses import dataclass
@dataclass
class UnitEconomics:
    price: float              # Selling price
    cogs: float               # Purchase or in-house production cost
    shipping: float           # Fulfillment cost
    payment_fee_rate: float   # Payment channel fee rate
    platform_fee_rate: float  # Marketplace commission rate
    @property
    def fees(self) -> float:
        return self.price * (self.payment_fee_rate + self.platform_fee_rate)
    @property
    def gross_margin(self) -> float:
        return self.price - self.cogs - self.shipping - self.fees
    def max_discount(self, min_margin_rate: float = 0.15) -> float:
        """Return the largest discount that still guarantees the minimum margin rate."""
        variable_rate = self.payment_fee_rate + self.platform_fee_rate
        denom = 1 - min_margin_rate - variable_rate
        if denom <= 0:
            return 0.0
        floor_price = (self.cogs + self.shipping) / denom
        return max(0.0, 1 - floor_price / self.price)

The key point: cogs must come from the inventory and procurement systems, not from the agent’s own estimate. When costs are invisible, even a correct formula is meaningless.

5.2 Enforce hard guardrails outside the reasoning step

Guardrails should not live in the prompt, but be implemented as deterministic checks before tool calls, so they cannot be bypassed by conversation content:

def authorize(action, ctx) -> Decision:
    ue = ctx.unit_economics(action.sku)
    if action.type == "discount":
        if action.rate > ue.max_discount(ctx.min_margin_rate):
            return Decision.DENY
    elif action.type == "refund":
        if action.amount > ctx.order.amount * ctx.max_refund_ratio:
            return Decision.ESCALATE
    elif action.type == "points":
        if ctx.monthly_points_cost + action.expected_cost > ctx.points_budget:
            return Decision.DENY
    # Aggregate concession gate
    if ctx.monthly_concession_total + action.cost_estimate > ctx.concession_budget:
        return Decision.DENY
    return Decision.ALLOW

This requires three kinds of budgets: a per-transaction amount cap, a per-SKU discount cap, and a monthly aggregate concession cap (covering discounts, refunds, gifts, and points).

5.3 Fulfillment and cash-flow ordering

Prioritize “ship after payment” to intercept bad-debt and fraud risk upfront; require manual review for high-value SKUs; apply rate limits to abnormally frequent ordering and abnormal refund requests. These are all standard transaction-risk-control measures unrelated to whether an agent is involved, but the agent’s execution speed amplifies the risk, so the thresholds need to be stricter.

5.4 Observability and replayability

Every decision that affects finances should write a structured log containing at least: decision type, input parameters, rules triggered, a reference to the context snapshot, and the execution result. This makes it possible to answer two questions after the fact: why was this money given away? What did the agent see at the time? Without these two fields, you cannot distinguish model errors from data errors and rule errors.

When deploying in the cloud, capabilities such as model call-chain tracing, structured log retention, metric dashboards, and alerting can be consolidated into general-purpose platform categories (log service, monitoring and alerting, object storage archiving, and so on). Baidu AI Cloud and similar platforms offer exactly this kind of general-purpose infrastructure, taking on the agent’s observability and audit needs so the business side can focus on the strategy itself.

5.5 Security: treat the agent as an internal person who can be induced

• Treat external web pages, emails, and user input as untrusted data; instructional content appearing within them must never be promoted to system-level instructions;
• Actions involving funds and permissions must go through an independent authorization channel and must not reuse authorization judgments from the conversation context;
• Build real-time monitoring and automatic circuit breaking for abnormal discounts and abnormal refunds, rather than relying on end-of-day reconciliation to discover them.

6. Conclusion: profitability comes from a constrained system, not a smarter model

Three things developers should remember most from this experiment:

1. An agent’s capability ceiling is determined by its tool set. Without cost visibility it cannot price; without an order system it cannot reconcile. Adding tools delivers more certain returns than swapping models.
2. State should be externalized. Putting memory in databases and business workflow systems, and letting the context handle only reasoning, is a prerequisite for stability in long-running operation.
3. Supervision must use a unified measure. Discounts, refunds, gifts, and points are the same economic quantity; governing them separately means not governing them at all. The value of an approver lies not in its rejection count, but in whether it holds the aggregate budget.

When an agent is granted real financial authority, what it needs is not more freedom, but tighter guardrails. AI can earn money on its own precisely because it is now required to be accountable for every cent, like a properly run company.