AI agents in the United States: rules and how to build

The United States has no general federal statute that regulates AI use by private companies. The binding duties for an agent deployer come mainly from state law, from existing sector rules and from consumer protection law. The federal government has tried to shape the state laws, but that effort does not, by itself, change them. The practical question for a builder is therefore not "what is the US rule", but "which states and which decisions does this agent touch".

What buyers here ask me first

Agents that look good in a demo and fail in the third week of real use. The gap is usually in the tools, the data access and the checks, not in the model.
Cost per completed task, not cost per call. A cheap call that needs rework is not cheap.
Evaluation coverage before launch, and who keeps it current afterwards.
Ownership after the vendor leaves. The system must be run by someone inside the company, with a handover that works.
State-law exposure when an agent touches hiring, lending or customer eligibility decisions.

The federal position

Executive Order 14365, signed in December 2025, directs the Attorney General to set up a task force to challenge state AI laws that conflict with a national framework. The order also asks other federal bodies to review state laws. An executive order cannot itself override a state law. That needs an act of Congress or a valid federal regulation, and the courts decide whether a particular state law falls. The order's proposed legislative framework would not seek to preempt state laws on child safety, data centre infrastructure, or state government procurement and use of AI.

A general federal AI statute for private deployers does not exist. A federal discussion draft has been circulated, but it has not passed. Law firms advise employers to keep complying with state law until a court or a statute says otherwise, and that is the advice I give clients.

The NIST AI Risk Management Framework is voluntary. It gives a common vocabulary for governing and measuring AI risk, and it is the reference most US buyers use when they ask for evidence. It does not create legal duties, but a risk team that adopts it will ask for the records it describes.

The state laws that touch agents

Employment decisions. Illinois HB 3773 covers employers that use AI in employment decisions. It took effect on 1 January 2026. An agent that screens, ranks or scores candidates falls in scope. The duties concern notice and how the tool is used, so the design needs to make both visible. The statute itself should be read for the exact duties.

Consumer decisions. Colorado's original AI Act, SB 24-205, was repealed and replaced before its main obligations took effect. The replacement, SB 26-189, is due to take effect on 1 January 2027. The sources disagree on whether enforcement of the original law was paused during a court case. Older coverage still describes 2026 duties as binding, and those descriptions are out of date.

Frontier developers. California's SB 53 covers large developers of frontier models, with a revenue threshold. It does not generally reach a company that deploys someone else's model inside its own product. A builder should check the definition before relying on that conclusion.

Other states. Several other states have enacted or proposed AI rules for specific uses, such as disclosure or automated decisions. The list changes often, so each deployment needs a current check against the states where the affected people live.

How an agent is built to meet these laws

The state laws ask for the same things in different words: notice, an explanation, a way to contest a decision, and a person who can review it. Those are engineering features, and they are easier to build than to argue later.

Context and data. The agent should read only the data the decision needs, and the record of what it read should be kept. For employment and lending uses, the inputs are the main place where a state law will look for fairness problems, so they must be documented.

Tools. Each tool the agent can call has a written contract, with its permissions stated. A tool that makes or records a decision about a person should require a named reviewer, and the review should be logged.

Controls. Guardrails block actions outside the agreed scope and flag decisions that need a person. They also make the notice to the affected person part of the workflow, not an afterthought.

Evaluations. An evaluation set built from real cases, with expected outcomes agreed by the business owner, is the evidence that the controls work. It is run after every change. For a hiring or lending use, the evaluation set should include cases where the outcome must not differ by protected characteristic, and the test results should be kept.

Records. A run log for each decision, the version of the model and the rules in force, and the owner's sign-off make the system defensible. These are also what a state regulator will ask for first.

The harness engineering term sets out the parts around the model that carry most of this work.

Where the picture is still moving

Colorado's replacement law is not yet in force, and the sources disagree on the status of the earlier enforcement. Federal preemption is contested in the courts, and the outcome of those cases will change which state laws survive. Before a US deployment, the questions to answer are which states the affected people live in, which decisions the agent influences, and which of the laws for those states apply to that decision.

What a first project looks like

The first project is one workflow, one owner and one decision the agent influences. I start with a readiness review of two weeks, which ends in a written decision to proceed, reframe or pause. For a US project, the review's first task is to list the states where the affected people live, because that list decides which laws apply. The second task is to list the decisions the agent makes or influences, and whether any of them concern employment, credit, housing or insurance.

If the project proceeds, the first working slice runs on real data outside production. It is scored against an evaluation set agreed with the business owner, and for any decision about a person, the set includes cases where the outcome must not depend on a protected characteristic. The handover then passes the agent to a named owner, with a runbook, the evaluation results and the record of decisions. Each step leaves a document a state regulator or a risk team can read.

Where the sources disagree

The status of Colorado's law is the clearest disagreement. Some sources describe the original statute as suspended during a court case, and others describe it as repealed and replaced. The replacement is reported to take effect on 1 January 2027. The state's own statute is the reference. The status of federal preemption is also disputed, and the answer will depend on court decisions. The effect of the executive order on any particular state law should be read from the court record, not from summaries of the order.

A composite example

[Composite] A regional lender wanted an agent to summarise loan applications for underwriters. The readiness review found that the summaries included postcode data, which can act as a proxy for protected characteristics. The team removed the postcode field from the agent's view, tested the summaries against a set of matched applications, and required an underwriter's sign-off on every decision. The evaluation results and the sign-off log became the file a state examiner would ask for.

A checklist before launch

Before an agent that touches a person's employment, credit, housing or insurance goes live, the following should be on paper: the list of states where the affected people live and the laws that apply to each; the decisions the agent influences and who makes the final decision; the notice the affected person will receive and where it appears; the route for a person to contest a decision and who answers it; the evaluation results, including the cases where outcomes must not differ by group; the run logs and their retention period; and the named owner with the authority to pause the agent. Each item is a document a regulator or a risk team can read, and each is easier to write before launch than after a complaint.

Common questions

Do US state AI laws apply to a company outside that state?

Often they depend on where the affected people live, not where the company is based. That is a legal question. The design answer is to find out which residents an agent's decisions affect, and to meet the rules for those states.

Is there a federal AI law I need to follow?

Not a general one for private deployers. Sector rules and existing consumer protection law still apply, and the state laws described above are the main binding obligations today.

Does the federal executive order stop state AI laws?

Not by itself. An order cannot override a state law. Courts decide which laws survive, so a company should keep complying with state law unless and until a court or statute says otherwise.

Does California's SB 53 apply to my agent?

Most enterprise deployers are not covered, because the law targets large developers of frontier models. If your company builds frontier models, the definition should be checked in full.

Is NIST's framework required?

No. It is voluntary. It is useful because it gives a common structure for the evidence a risk team asks for.

What evidence do US buyers ask for before launch?

Usually the evaluation set and its results, the list of tools and their permissions, the run logs, the named owner and the handover plan. These are the same records the state laws ask a deployer to keep.

Why not just use a larger model?

A larger model can help with some tasks. It does not fix missing data access, unclear decision rules or the absence of an owner. Those are the usual causes of failure in production, so they should be addressed first.

Resources

Engagements: the shapes of work I offer. I do not publish prices.
Harness engineering: the parts around a model that make an agent reliable.
Human in the loop: when a person must approve or stop an action.
Responsible AI controls: the controls written down before a build.
Harness engineering: the model plus everything around it: the long form of the framing used on this page.
Specification-driven development: writing the specification before the agent is built.

Work with me

If you are deciding whether an agent should be built for a US workflow, start with the AI Delivery Readiness Review. It is a two-week check on one workflow that ends in a written decision to proceed, reframe or pause. For teams that want to build the capability themselves, the AIXL Academy forward-deployed AI engineering cohort is the route, with its own schedule and terms on that page. I work with US teams on engagements, and I travel for engagements. The work location is stated in each engagement. You can also send an enquiry.

Work with me in the United States

Work with me in the United States: Pacific time overlap, state rules and the engagement shapes.
FDE consulting in the Bay Area: forward-deployed AI consulting for Bay Area teams building agents for US customers.

This page summarises public sources as of the date above. It is not legal advice. Where sources disagree, the page says so. Sources marked as commentary are secondary and should be checked against the official text before a decision.

This page summarises public sources as of the date above. It is not legal advice. Where sources disagree, the page says so.

AI agents in the United States