Forward-deployed AI consulting for Bay Area teams
Bay Area teams build agents that touch customers, employees and money. The engineering is the familiar part. The part that slows a launch is the set of questions a team must answer before the agent runs: which state's law applies to a decision, who can see what the agent reads, which actions need a person's approval, and how the team will know the agent still works after the next model update.
I am Mayur Patil, based in Nashik, India. I work with Bay Area teams on forward-deployed AI consulting, from India, with on-site discovery arranged per engagement. The work is built to answer the questions a US risk or legal team asks, in the order they ask them.
What the US rules mean for an agent
There is no general federal statute for AI use by private companies. The binding duties come from state law and sector rules. The federal executive order of 16 December 2025, EO 14365, directs a federal task force to challenge state AI laws, but an executive order does not change a state law by itself. Courts decide which laws survive, so a design has to keep complying with state law until a court or a statute changes it.
The state laws that touch agents most often are the employment and consumer laws. Illinois HB 3773 took effect on 1 January 2026 and covers employers that use AI in employment decisions, including screening and ranking candidates. Colorado's original AI Act was repealed and replaced by SB 26-189, which takes effect on 1 January 2027. California's SB 53 applies to large developers of frontier models, and most companies that deploy a model do not fall under it. The United States pillar sets out each of these with its source.
Which state's law applies
The test is not where the company is based. It is where the affected people live, and what the agent decides or influences. A claims-triage agent for customers across several states touches the laws of each state where a customer lives. A hiring agent that ranks candidates touches the law where the candidates apply, and the employment statute is the first place to look.
The readiness review makes this concrete. It lists the states involved, the decision each step makes, and the current text that governs it. It records the text it checked and its date, because the position changes.
The NIST framework and the evidence file
The NIST AI Risk Management Framework is voluntary, and it gives the vocabulary that most risk teams use. Its four functions are govern, map, measure and manage. For an agent, govern is the named owner and the approval rules. Map is the list of decisions and the data each step reads. Measure is the evaluation set and its results. Manage is the stop control, the monitoring and the process for a model update. A team that keeps these four in one file can answer most review questions from it.
Pilots that stall in the Bay Area
Three reasons come up most often. The state-law question is answered after the build, when it should have been part of the design. The evaluation is a demonstration rather than an agreed test set. And the agent can act, but nobody has written the list of actions that need a person to approve them.
A fourth reason is the handover. A team that built the agent with an outside partner needs to know who runs it in the morning, and what the runbook says to do when the agent fails. The handover pack names that person and lists the decisions behind the system.
What the readiness review produces
The AI Delivery Readiness Review is two weeks on one workflow. It produces four things, all written:
- A state map. Which states' laws touch the agent, the decisions it makes, and the text checked on a stated date.
- A data map. The personal data each step reads, and the access the agent should have.
- An approval list. Each action that changes a record, sends a message to a customer or makes a decision about a person, with the named approver.
- An evaluation plan. The test cases, the expected outcomes and the owner who signs them off.
The review ends with a recommendation to proceed, reframe or pause. A pause is a valid result, and it is written with the reasons.
One example use case
The example below is an illustration of the work, not a client engagement.
Example: a security-questionnaire agent. A software company receives security questionnaires from enterprise customers, each with a few hundred questions, and its sales engineers answer them by hand. The proposed agent drafts answers from an approved library, cites the source for each answer, and sends any new or unclear answer to a named security reviewer. The readiness review found three things to settle first. Customer documents contain personal data of the customer's staff, so the agent reads only the questionnaire and the approved library. A new answer is never sent without a reviewer's approval. And the evaluation set is built from past questionnaires whose answers the security team has already signed off. The first working slice ran on past questionnaires, and the evaluation showed which kinds of question the library covered poorly, which became the next task.
Working across time zones
I run back-to-back full-day corporate trainings, mostly in IST. Some programmes run in US Pacific (Bay Area) time for US-based teams. Pacific time differs from India time by more than twelve hours, and the offset changes with daylight saving, so the overlap for decisions is set for each project rather than assumed. A typical pattern is a short overlap at the start of the Pacific day for decisions, with build work done in India overnight and reviewed in the morning.
How an engagement runs
An engagement starts with the two-week AI Delivery Readiness Review on one workflow, and it ends with a written recommendation to proceed, reframe or pause. If the work proceeds, an architecture sprint or a forward-deployed delivery engagement follows, with a handover to a named owner who runs the agent after launch.
Three ways to start
AI Delivery Readiness Review. Two weeks on one workflow, with a written readout.
Architecture Sprint. Two to four weeks on one use case, with the architecture, the decisions and a backlog.
Forward-deployed AI delivery. One bounded use case, built inside your systems, with a runbook and a named owner.
Each is quoted on its scope. The engagements page describes what each includes. I do not publish prices.
Relevant work
The organisations I have worked with and can name are listed on the about page. Among them are Tredence, Persistent and Walmart. Walmart's procurement teams have been through my programmes on Microsoft 365 Copilot and agent tooling, which is the kind of enterprise workflow a Bay Area team also runs.
Where to go next
The FDE consulting hub covers the three ways to engage. For the rules, the United States pillar is the reference. For the programmes, the FDE training hub describes the team and cohort routes.
Common questions
Do state AI laws apply to an agent we build for customers outside our home state?
It depends on where the affected people live, not where the company is based. The readiness review lists the states involved and the decisions the agent influences, and it checks each state's current text before the design is fixed.
Does an agent that screens job applicants fall under a state law?
Illinois HB 3773 covers employers that use AI in employment decisions, and it took effect on 1 January 2026. An agent that screens or ranks candidates falls in scope, so the design includes the notice the statute requires.
Does the federal executive order of December 2025 stop state AI laws?
Not by itself. An executive order cannot override a state law. Courts decide which laws survive, so the design keeps complying with state law until a court or statute changes it.
Can you run the work in US working hours?
Some programmes run in US Pacific time for teams in the Bay Area, and the overlap for decisions is agreed per engagement. Pacific time differs from India time by more than twelve hours, and the offset changes with daylight saving, so the overlap is set for each project.