AI agents are increasingly being pitched as more than tools for creating websites, campaigns, research, and other business assets. The next proposition is that they can operate parts of the growth engine: identifying opportunities, producing and distributing material, updating systems, and adapting subsequent actions to results.
Runable illustrates this shift. According to TechCrunch, the company is expanding its proposition from helping users build businesses toward helping them grow. The company also says paying customers accounted for 60%–70% of its more than one trillion tokens of usage during the previous 90 days. That is vendor-reported evidence of substantial paid use, but it is not proof that customers achieved positive returns. Token consumption measures activity, not incremental revenue, savings, or quality.
Operators therefore need to evaluate an agent as an operating system participant—not merely as a content-generation tool. The central question is whether it can improve a bounded growth workflow without creating disproportionate financial, security, operational, or brand risk.
Begin with a bounded growth workflow
“Grow the business” is not an executable brief. An initial workflow should have a defined trigger, inputs, permitted actions, output, owner, and completion state. It should also be reversible when possible.
Suitable early candidates may include preparing account research for sales representatives, drafting personalized outreach for approval, generating campaign variants within an approved message library, classifying inbound leads, identifying dormant accounts for review, or assembling weekly performance summaries. Each gives the agent a constrained objective while preserving human control over consequential decisions.
Avoid starting with workflows in which an error can immediately become public, expensive, or legally significant. Examples include autonomously changing prices, publishing unsupported product claims, committing contract terms, approving refunds, deleting customer records, or sending high-volume outreach without review. These may eventually be candidates, but only after the agent has demonstrated reliability under narrower permissions.
Write the pilot boundary in operational terms: “The agent may analyze approved CRM fields and prepare up to 20 re-engagement drafts per day; a named employee must approve every send.” This is testable. “Use AI to improve retention” is not.
Map access and approval gates before connecting systems
Agent usefulness often depends on access to CRM records, analytics, email, content management, advertising, customer-support, or billing systems. That same access defines the potential blast radius. Operators should map every requested permission to a specific step in the chosen workflow.
Use least-privilege access. Read-only access may be sufficient for analysis; draft status may be enough for content; a sandbox can validate integrations before production use. Separate permission to recommend an action from permission to execute it. Credentials should be revocable, attributable to the agent rather than shared with a person, and covered by existing logging and incident-response processes.
Approval gates should reflect consequence, not just task type. A low-risk internal summary may be released automatically if it passes validation. Customer-facing communication should generally require review during the pilot. Changes involving spend, pricing, personal data, contractual commitments, or regulated claims require stronger controls and, in some cases, should remain outside the agent’s authority.
Define escalation rules as well. The agent should stop and ask for help when source data is incomplete, instructions conflict, confidence is low, an action exceeds a budget threshold, or a customer request falls outside approved policy. Silence should never be interpreted as approval for a high-impact action.
Test output quality in the context of the workflow
A fluent output can still be commercially wrong. Quality assessment must reflect the job being delegated. For account research, test factual accuracy, relevance, freshness, and traceability to sources. For outreach, assess brand alignment, personalization accuracy, legal compliance, and whether claims are supported. For lead classification, compare decisions with an agreed rubric and examine false positives and false negatives separately.
Create a representative evaluation set before launch, including ordinary cases, missing fields, ambiguous instructions, unusual customer situations, and adversarial or misleading inputs. Have the workflow owner establish a baseline using the current process. The agent should then be judged against that baseline rather than against an abstract impression of intelligence.
Review downstream effects, not only outputs. A higher volume of messages is not an improvement if complaints rise or sales teams receive poorly qualified responses. Faster content production has limited value if employees spend the saved time correcting facts and tone. Track rework rates, exception rates, approval rejection, customer complaints, and incidents alongside speed and volume.
Separate usage, efficiency, and incremental growth
Runable’s reported token usage may indicate that paying customers are actively using the product. It does not reveal the cost per successful outcome, what portion of usage was productive, or whether results would have occurred without the agent. Operators should resist adopting activity metrics as ROI metrics.
For cost savings, establish the current human time, external spend, error burden, and processing volume for the bounded workflow. Then include all agent-related costs: subscription or platform charges, token or model consumption, integration work, monitoring, employee review, rework, and incident handling. Gross time saved is not automatically a cash saving unless that capacity can be redeployed or an expense can actually be removed.
For revenue workflows, choose a credible comparison. Depending on volume, this could be a holdout group, staggered rollout, matched set of accounts, or comparison with the previous manual process. Measure qualified opportunities, conversion, retained revenue, or another business outcome appropriate to the workflow. Avoid crediting the agent for all revenue that followed an agent-assisted touch.
Token-related costs deserve specific monitoring because autonomous systems may iterate, call tools, revisit tasks, or run continuously. Track tokens and total cost per completed workflow, accepted output, qualified lead, or other useful unit. Set per-run, daily, and monthly limits. Investigate loops, repeated retrieval, unnecessarily long context, and low-value background activity before they become normal operating expense.
Set security requirements and stop conditions in advance
Before supplying data, operators should document what the agent receives, where that data is processed and retained, whether it may be used to train models, which subprocessors are involved, and how deletion works. Sensitive customer information, credentials, payment data, confidential strategy, and regulated records require particular scrutiny. Data minimization is preferable to relying solely on contractual assurances.
Logging should show what information the agent accessed, what it generated, which tools it called, what actions it attempted, who approved them, and what ultimately happened. Without this audit trail, diagnosing a bad outcome or disputed action becomes difficult.
Stop conditions turn oversight into an enforceable policy. Pause the pilot if costs exceed the agreed ceiling, error or rejection rates cross a threshold, the agent attempts an unauthorized action, customer complaints rise, attribution cannot be established, or review effort eliminates the expected benefit. Include a kill switch, credential-revocation procedure, rollback plan, and named decision owner.
An operator checklist for an adoption decision
- Workflow: Is the task bounded, measurable, reversible, and supported by reliable inputs?
- Access: Does every system permission correspond to a necessary action, with least privilege and separate credentials?
- Oversight: Which outputs require approval, and which conditions force escalation?
- Quality: Is there a representative test set, baseline, acceptance rubric, and process for reviewing failures?
- Security: Are data handling, retention, training use, subprocessors, deletion, and audit logs understood?
- Economics: Are platform, token, integration, review, rework, and incident costs included?
- Attribution: Can incremental revenue or realized savings be distinguished from ordinary activity?
- Limits: Are budgets, action thresholds, prohibited tasks, stop conditions, and rollback procedures configured?
The practical opportunity is not to hand an agent an unrestricted growth mandate. It is to give it a narrow operating role, observe whether it produces accepted outcomes at an acceptable total cost, and expand authority only when evidence supports doing so. Vendor-reported usage can justify investigation; only controlled results inside the operator’s own workflow can justify adoption.
