When an AI agent makes a bad decision, “the agent did it” is not an operating model.
Federal Trade Commission Chairman Andrew Ferguson made that point directly on September 25. Speaking at Reuters Momentum AI Austin, he rejected descriptions of AI agents as independent actors with wills of their own and suggested responsibility should remain with the people or companies that instruct and control the tools.
His comments do not settle every legal question around AI agents. They do reinforce a practical rule for manufacturers, distributors, commerce operators, and service businesses: automation can execute work, but the business still needs to own the instruction, authority, oversight, exception, and outcome.
What the FTC chair said
In its September 25 report, Reuters described Ferguson’s resistance to “anthropomorphizing” AI tools. He argued that if someone instructs a tool to act, the response should focus on the responsible people and organizations rather than treating the tool as a separate actor.
Ferguson also said the United States should first use existing legal tools. Reuters reported that he raised the possibility that FTC authority concerning undisclosed data breaches could apply to AI developers in appropriate circumstances.
That position is consistent with a longer FTC theme. In 2024, the agency said there is no AI exemption from existing prohibitions on unfair or deceptive conduct. In separate remarks, the FTC described a principle of aligning liability with capability and control across the AI stack.
What changed—and what did not
The new development is a current statement from the FTC chair about how he views AI-agent responsibility and the usefulness of existing legal authority. It is relevant because businesses are moving from assistants that draft content to agents that can call APIs, access records, send messages, modify systems, and initiate transactions.
The remarks are not a new law, regulation, court judgment, or universal allocation of liability. They do not establish that the model developer is always responsible, that the deploying business is always responsible, or that contracts and industry-specific rules no longer matter. Actual legal responsibility will depend on the facts, applicable law, contractual obligations, control, foreseeability, and conduct of multiple parties.
The operational inference is much clearer: a company should not design an agentic workflow with an accountability gap.
Assign ownership before granting authority
Every production AI workflow should have named owners for six different responsibilities. One person may hold more than one role, especially in a smaller business, but the roles still need to exist.
- Business owner: accountable for the outcome the workflow is meant to improve and for deciding whether automation is appropriate.
- Technical owner: responsible for integrations, credentials, model configuration, releases, monitoring, and rollback.
- Data owner: determines which records and fields the workflow may access, retain, or send to a vendor.
- Approval owner: has authority to approve defined high-consequence actions and change approval thresholds.
- Exception owner: resolves ambiguous, conflicting, or failed cases before they become unowned backlog.
- Incident owner: can pause the workflow, revoke access, reconcile uncertain actions, notify affected parties, and coordinate recovery.
If nobody can be named for one of those responsibilities, the workflow is not ready for production authority.
Keep an instruction-to-action record
Accountability requires more than a list of names. The company needs to reconstruct what happened.
For consequential actions, preserve the source event, approved workflow version, relevant instructions, model and version, systems and records accessed, validation results, proposed action, approval decision, system response, exception, and final outcome. Do not log sensitive data merely for the sake of logging; retain the minimum evidence needed to explain and reconcile the action.
This record answers the practical questions that follow an error:
- What was the agent asked to do?
- Which permissions made the action possible?
- Which rule or source of truth should have constrained it?
- Did a required approval occur?
- What changed in the model, prompt, integration, data, or operating environment?
- Which transactions or customers were affected?
- Can the action be reversed safely?
- Who decides when the workflow may resume?
That is why AI governance must be implemented inside the workflow rather than left as a policy document.
A manufacturing example: the agent promises a ship date
Suppose an AI agent reads an RFQ, checks inventory, prepares a quote, and emails the customer. The model interprets a substitute item as available and promises a ship date the plant cannot meet.
Calling that an “agent mistake” does not help the customer or the operation. The useful review is concrete:
- Was the substitution rule explicitly defined?
- Did the workflow query available inventory, allocated inventory, or an outdated copy?
- Was production capacity part of the validation?
- Should nonstandard substitutions have required sales or operations approval?
- Who owns the customer correction and revised commitment?
- Can similar pending quotes be identified and stopped?
A controlled RFQ-to-quote workflow lets AI interpret documents and draft the response, while deterministic rules validate the customer, SKU, price, margin, inventory, lead time, and required approvals. Exceptions go to a named owner with the source evidence and proposed resolution.
A commerce example: automated refunds
An agent that answers product questions carries different consequences than one that issues refunds, changes prices, or updates fulfillment instructions. The latter needs narrowly scoped authority, transaction limits, duplicate prevention, fraud checks, approval thresholds, and reconciliation.
If a refund agent begins approving unusual requests, monitoring should detect changes in amount, frequency, customer pattern, override rate, or reason code. The incident owner should be able to suspend refund writes without taking the entire customer-service operation offline. Open cases should move into a visible manual queue.
Bridge Road’s commerce and operations work treats manual fallback as part of the production design—not an improvised response after a failure.
Review the vendor contract and the full responsibility chain
Operational ownership does not mean the deploying business accepts every possible obligation from every vendor. Model providers, software platforms, integrators, data suppliers, and users may each control different parts of the system.
Before deployment, review data-use terms, security commitments, incident notification, service levels, model-change notices, audit access, limitations of liability, indemnification, subcontractors, retention, and termination support. Compare those terms with the workflow’s actual use. Agentic actions, custom integrations, customer-provided data, and downstream modifications may sit outside protections described in a general sales presentation.
Maintain enough portability that a vendor outage, policy change, or contract dispute does not stop the underlying business process. The manual procedure, source data, rules, pending queue, and system-of-record access should remain under business control.
The practical standard: no ownerless automation
The FTC chair’s remarks should not be read as a final legal formula. They are a timely reminder that attaching a human-like name to software does not remove the people, permissions, instructions, systems, and business decisions behind it.
Use AI aggressively where it releases capacity and improves service. But before an agent receives production authority, require five things: a named owner, a bounded action set, independent validation, a reconstructable audit trail, and a tested recovery path.
Bridge Road helps businesses build that accountability into business systems, automation, commerce, and operations. The goal is not to make every decision manual. It is to make sure every automated decision still belongs to the business.
