The first wave of enterprise AI was built around answers.
A company connected a large language model to its documents, gave employees a chat box, and hoped the system could answer questions faster than a person could search through folders, emails, databases, and internal tools.
The next wave is very different.
AI is starting to act.
An AI agent can open software, call an API, search a database, write code, create a report, update a record, send a message, trigger another system, wait for an approval, continue several hours later, and coordinate with other agents.
That changes the infrastructure problem completely.
A chatbot mostly needs a model, data, and an interface. An autonomous agent needs something closer to an operating environment. It needs somewhere to run, rules about what it can access, memory about what already happened, tools it can use, a way to recover when something fails, logs showing what it did, limits on what it is allowed to change, and a process for handing important decisions back to a human.
This is why one of the most important parts of the AI market may not be the agents employees see.
It may be the invisible infrastructure underneath them.
New York is becoming an interesting place to watch this layer develop. NYCEDC says New York City has more than 2,000 AI startups, more than 40,000 workers with AI-related skills in the metro area, more than 1,200 active venture firms, and more than 25,000 technology-enabled startups. The city’s universities produced more than 87,000 AI-ready degree holders between 2018 and 2023.
That matters because New York is not only producing AI companies. It is full of the enterprises that agent infrastructure is supposed to serve.
Banks, hedge funds, insurers, law firms, media groups, retailers, healthcare organizations, real estate companies, advertising agencies, logistics businesses, and Fortune 500 companies all operate complex systems here. Many of those companies cannot simply give an AI model a password and hope for the best.
They need an operating layer between intelligence and action.
Our research suggests that layer is beginning to take shape.
The Short Version: The Enterprise AI Battle Is Moving Below the Chat Window
The most important enterprise AI question is starting to change.
In 2023 and 2024, many companies asked, “Which model should we use?”
Then they asked, “Which AI assistant should we give employees?”
Now a more difficult question is emerging:
What infrastructure must exist before AI agents can safely run parts of the company?
That question creates an entirely different software market.
An autonomous enterprise needs systems for execution, orchestration, permissions, context, memory, identity, monitoring, evaluation, recovery, human approval, and governance. No single model provides all of those things.
A model can decide that an invoice looks wrong. Something else has to retrieve the invoice, understand the company’s purchasing rules, check previous transactions, determine whether the model is allowed to contact the supplier, record the action, ask a manager for approval when necessary, and resume the process when that approval arrives.
That “something else” is becoming the agent operating layer.
Several New York companies are attacking different parts of it.
Daytona is building isolated computers where agents can safely execute code. Thread AI is building infrastructure for controlled enterprise workflows. Emergence AI is working on multi-agent orchestration. Hatchet provides durable execution for long-running agents and workflows. Credal is building governance and permission infrastructure. AI One is developing a context and governed-execution layer. Modal is building the underlying compute infrastructure used by AI workloads. Strange Loop is taking many of the same ideas into institutional finance. General Intelligence Company is pushing further toward an agent-native company platform.
The important point is not that one of these companies will become “Windows for AI agents.”
The more useful way to think about the market is that enterprises are building a new software stack.
What Is an AI Agent Operating System?
The phrase “AI agent operating system” can easily become meaningless marketing language, so we need a practical definition.
For this article, an AI agent operating system means the infrastructure that lets autonomous software receive work, understand business context, use tools, execute actions, remain within permissions, recover from failures, and produce an auditable record of what happened.
It does not have to be one product.
In fact, it probably will not be.
The Old Enterprise Stack Was Built Around Human Users
Traditional business software assumes a person is operating it.
A person logs into Salesforce.
A person approves a payment.
A person downloads the spreadsheet.
A person checks the numbers.
A person writes the email.
A person decides which system to open next.
The software can therefore depend on the employee to provide judgment, sequence, context, recovery, and supervision.
An agent changes that assumption.
If software is supposed to complete the workflow itself, many of the responsibilities that used to sit inside the employee’s head need to become explicit parts of the technology stack.
The Agent Stack Needs Several New Layers
A useful way to understand the emerging architecture is to divide it into eight functions.
| Layer | What it does | Why an autonomous enterprise needs it |
| Model layer | Reasoning, language, planning and generation | Provides the intelligence |
| Context layer | Gives the agent relevant company data and business meaning | Stops the model from operating with incomplete information |
| Tool layer | Connects agents to APIs, databases and software | Lets the agent do something instead of only answer |
| Execution layer | Runs code and tasks in controlled environments | Lets actions happen without exposing core infrastructure |
| Orchestration layer | Coordinates steps, agents, triggers and dependencies | Turns isolated actions into workflows |
| Permission layer | Controls what each agent can read, write or execute | Limits the damage from mistakes or attacks |
| Reliability layer | Checkpoints, retries, evaluates, monitors and records work | Makes long-running automation usable in production |
| Human-control layer | Routes exceptions and high-risk actions to people | Keeps accountability inside the organization |
An enterprise may buy these capabilities from several companies.
That is similar to what happened with the cloud. Amazon Web Services did not remove databases, security software, observability tools, identity systems, developer platforms, and data infrastructure. It became part of a much larger stack.
Agent infrastructure is likely to develop the same way.
Original NYC Tech Journal Research: Mapping New York’s Emerging Agent Infrastructure Market
To understand whether this is a real New York technology category rather than a collection of interesting demos, NYC Tech Journal created a snapshot of the local ecosystem.
Our Methodology
We started with AI Atlas NYC’s publicly available company map as a consistent classification source. As of our September 17, 2026 research snapshot, the map contained 74 NYC AI companies across 10 categories. Ten companies were classified specifically as Agent Infrastructure. The broader database also marked 38 companies with a workflow signal.
We then reviewed the public descriptions of the 10 infrastructure companies and manually assigned each company one primary infrastructure role. A company may obviously perform several functions, but assigning one primary role prevents double counting.
For the funding analysis, we included only companies where a latest-round dollar amount was publicly shown in the dataset. We did not estimate missing rounds, valuations, or undisclosed investment.
We then compared the dedicated infrastructure sample with other New York companies whose products clearly touch execution, compute, governance, orchestration, or enterprise context, including Hatchet, Credal, Modal, AI One, and Strange Loop.
This is not intended to represent every AI infrastructure company in New York. It is a transparent market snapshot designed to show where the local stack appears to be forming.
Chart 1: Dedicated Agent Infrastructure Is Already a Visible Part of the NYC AI Sample
| NYC AI Atlas snapshot | Companies | Share of 74-company sample |
| Dedicated Agent Infrastructure | 10 | 13.5% |
| Companies carrying a broader workflow signal | 38 | 51.4% |
| Total mapped companies | 74 | 100% |
Source data: AI Atlas NYC. Percentages calculated by NYC Tech Journal.
The dedicated infrastructure number is interesting.
About one in seven companies in this sample sits directly in agent infrastructure. Yet more than half of the map carries the broader workflow signal.
That gap may tell us something important.
The agent economy is developing in two directions at once.
One group of startups is building the plumbing.
Another, much larger group is using that plumbing to automate specific jobs.
The ratio between the 38 workflow-signal companies and the 10 dedicated infrastructure companies is 3.8 to one.
That is exactly what we would expect if infrastructure were becoming a multiplier rather than the final product.
Chart 2: NYC Agent Infrastructure Is Still an Early-Stage Market
Our 10-company infrastructure sample breaks down as follows.
| Stage | Companies | Share |
| Series A | 3 | 30% |
| Seed | 5 | 50% |
| Pre-seed | 1 | 10% |
| Other early stage | 1 | 10% |
The three Series A companies in the sample are Daytona, Emergence AI, and Thread AI. Five companies are classified as seed-stage, while Empromptu is pre-seed and Kay.ai is listed more broadly as early stage.
This does not look like a mature enterprise-software category yet.
It looks more like a market whose architecture is still being decided.
That should matter to buyers.
When an enterprise selects agent infrastructure in 2026, it should assume products will change quickly, categories will merge, and some features that currently require separate vendors will eventually become standard parts of larger platforms.
Chart 3: Disclosed Capital Is Heavily Concentrated in a Few Infrastructure Bets
Six companies in the 10-company sample had clear latest-round dollar amounts available in our source data.
| Company | Latest disclosed round used in analysis |
| Emergence AI | $97.2M |
| Daytona | $24.0M |
| Thread AI | $20.0M |
| General Intelligence Company | $8.7M |
| Vibranium Labs | $4.6M |
| Empromptu | $2.0M |
| Total | $156.5M |
Sources: company and ecosystem data.
This is not total funding raised by NYC agent infrastructure. It is simply the sum of the latest disclosed rounds for these six companies.
Even with that limitation, the distribution is revealing.
The three Series A rounds account for approximately 90.2% of the $156.5 million in this measured pool.
Emergence AI and Daytona alone account for about 77.4%.
Capital is therefore not spread evenly across dozens of interchangeable agent tools.
Investors appear willing to make much larger bets when a company starts looking like foundational infrastructure.
Chart 4: The NYC Infrastructure Market Is Already Splitting Into Specialties
We manually coded the primary product wedge of the 10-company Agent Infrastructure sample from their public descriptions.
| Primary infrastructure role | Companies | Share |
| Orchestration and workflow execution | 5 | 50% |
| Sandboxed execution and coding infrastructure | 2 | 20% |
| Data and context infrastructure | 2 | 20% |
| Operational reliability / incident automation | 1 | 10% |
This classification is NYC Tech Journal’s analysis, rather than a category supplied by the companies.
The largest group is orchestration.
That makes sense.
An agent that can answer a question is relatively easy to demonstrate. An agent that can complete a 27-step business process across five systems while dealing with failure is much harder.
The harder problem is increasingly where infrastructure companies are moving.
Finding #1: Orchestration Is Becoming the Center of the Stack
The word “orchestration” sounds technical, but the idea is simple.
Someone has to decide what happens next.
Imagine an insurance agent processing a renewal.
It may need to retrieve last year’s policy, download a new carrier document, compare terms, extract changes, check the agency management system, identify missing information, draft a request, wait for a response, update records, and send the finished work for review.
That is not one prompt.
It is a sequence.
Some steps may take seconds. Others may stop for three days while someone responds.
The system therefore needs state.
It needs to remember where it is.
It needs to know what succeeded.
It needs to know what can be repeated.
It needs to know which action should require human approval.
That is why orchestration is becoming so important.
Thread AI Is Building the Enterprise Control Layer
Thread AI is one of the clearest New York examples.
The company describes Lemma as infrastructure for deploying controlled and governed AI workflows and agents. Its platform is designed to connect applications, APIs, AI models, and existing systems while providing governance and traceability. Thread announced a $20 million Series A in June 2025 after a $6 million seed round.
The important word is not “AI.”
It is “workflow.”
Large companies already have software.
They have databases.
They have APIs.
They have identity systems.
They have decades of business rules.
They are unlikely to replace everything so that an agent can work.
The infrastructure opportunity is therefore to sit across the existing stack and make autonomous actions manageable.
The Enterprise Does Not Need Another Island
This is a major strategic point for buyers.
A company should be skeptical of an AI agent that creates another isolated software island.
The more powerful architecture is usually one that works across the systems employees already use.
That is where an orchestration layer starts looking like an operating system.
Emergence AI Is Pushing Toward Multi-Agent Orchestration
Emergence AI is taking the idea further.
The company has developed an orchestrator designed to coordinate multiple autonomous agents across enterprise systems. Its architecture can combine agents focused on web interfaces, APIs, data work, connectors, and other tasks. Emergence has also described work on systems where agents can create additional agents and assemble them around a task.
AI Atlas lists Emergence as a New York Agent Infrastructure company with a $97.2 million Series A.
This points toward a future in which the enterprise does not have one giant agent.
It has many specialized agents.
One agent understands customer records.
Another handles web interfaces.
Another checks compliance.
Another performs research.
Another writes code.
The orchestrator decides which one should work next.
That looks less like a chatbot and more like a software workforce.
Finding #2: Durable Execution May Become as Important as Model Intelligence
An agent completing a five-second request does not need much infrastructure.
An agent completing a five-hour process does.
The longer a workflow runs, the more opportunities there are for something to break.
A network request fails.
An API times out.
A browser session expires.
A computer restarts.
A human approval takes two days.
A model call returns an invalid answer.
The agent must not forget everything and begin again.
This is the problem durable execution solves.
Hatchet Is Building for Work That Cannot Simply Restart
New York-based Hatchet describes itself as an orchestration platform for AI agents, background tasks, and mission-critical workflows. Its system stores task state so work can be retried, replayed, monitored, or resumed after failure. The company says agents can checkpoint progress, pause for human involvement, and continue later. Y Combinator lists Hatchet as based in New York City.
This may sound like developer infrastructure far removed from business strategy.
It is not.
Durability determines which processes companies can safely automate.
If an agent can only handle tasks that finish immediately, it remains a useful assistant.
If it can survive failure, wait for events, maintain state, and resume reliably, it can start owning real operational processes.
That is a much larger market.
Finding #3: Agents Need Computers, Not Only APIs
One of the biggest mistakes in early agent architecture is assuming every business system has a perfect API.
It does not.
Enterprises still run old portals, desktop software, spreadsheets, browser tools, legacy databases, scripts, and internal applications.
Agents therefore sometimes need something resembling a computer.
Daytona Is Building Computers for Agents
Daytona describes its core product as a programmable, composable computer for AI agents.
Its sandboxes give an agent an isolated environment containing compute, memory, storage, networking, and an operating system that can be created, paused, resumed, forked, or snapshotted. The company announced a $24 million Series A led by FirstMark Capital in February 2026 and lists a New York office.
This solves a basic safety problem.
If an AI agent writes uncertain code, you probably do not want it running directly on a production server.
Put it in a sandbox.
Let it install packages.
Let it create files.
Let it make mistakes.
Let it fail.
Then destroy the environment when the task ends.
Sandboxes Could Become a Standard Enterprise Agent Primitive
The deeper idea is that future companies may provision computers for agents the way they currently provision laptops for employees.
The difference is scale.
A person might use one computer for several years.
An agent might create 200 temporary environments in a few minutes, test several approaches in parallel, keep the successful result, and destroy the rest.
Infrastructure designed around human users was never built for that pattern.
Modal Shows Why the Compute Layer Is Also Changing
New York-based Modal operates further down the stack.
Its infrastructure provides fast access to cloud compute, including GPUs, containers, inference infrastructure, sandboxes, and workloads used by AI applications. Modal’s headquarters are in New York City, and the company raised an $87 million financing in 2025 that reportedly valued it at $1.1 billion.
Modal is broader than agent infrastructure.
That is exactly why it matters.
Agent platforms eventually hit physical limits.
Every tool call uses compute.
Every parallel research task uses compute.
Every code agent needs an execution environment.
Every evaluation consumes resources.
Every agent running around the clock changes the economics of infrastructure.
The operating system for an autonomous enterprise therefore cannot be separated completely from the machines underneath it.
Finding #4: Context Could Become the New Enterprise Data Layer
Giving an agent access to information is easy.
Giving it the right information is much harder.
A model may see two records with similar company names and not understand that they belong to the same customer.
It may retrieve an old pricing document when a new policy exists.
It may know that an employee works at the company without knowing what that employee is permitted to see.
This is why context is becoming its own infrastructure problem.
AI One Is Building a Context and Governed-Execution Layer
AI One describes itself as a New York enterprise AI company building infrastructure underneath AI and agentic applications.
Its ContextOne product connects agents and AI applications to approved company context, systems, memory, permissions, and controls. The company says the goal is to make AI workflows repeatable without forcing every team to rebuild those pieces from the beginning.
This addresses a problem many enterprises are discovering.
More data does not automatically create better agents.
An autonomous system needs structured understanding.
It needs to know which customer a contract belongs to.
It needs to know which version is current.
It needs to know which source is authoritative.
It needs to know which employee is allowed to approve a change.
Context therefore becomes part of execution.
Kay.ai Shows How Context Turns Into Vertical Action
AI Atlas classifies Kay.ai in its Agent Infrastructure category and describes the company as providing a context and retrieval layer for enterprise documents.
Kay has also moved directly into autonomous insurance operations. In May 2026, it announced an autonomous agent designed to complete insurance back-office workflows across portals, documents, email, and agency systems.
That evolution is worth watching.
Infrastructure companies may start horizontally and then discover that the largest value sits inside a specific industry.
Or vertical agent companies may build so much internal infrastructure that parts of their stack later become platforms.
The boundary will remain messy.
Finding #5: Permissioning May Become the Agent Equivalent of Identity Management
Once an agent can act, permission becomes one of the most important design questions.
An employee may have permission to read a contract but not delete it.
A sales agent may be allowed to draft a discount but not approve one above 10%.
A finance agent may reconcile accounts but not move money.
A customer-support agent may issue a small refund automatically but require approval for a large one.
Those limits cannot remain buried inside prompts.
They need infrastructure.
Credal Is Building a Trust Layer Between Agents and Enterprise Systems
Credal describes its platform as a centralized trust layer for AI agents and MCP servers.
Its infrastructure provides governed access to company systems while enforcing permissions, auditing, and controls. Credal’s documentation describes permission mirroring, human approval for selected actions, and audit trails recording actions initiated and executed by AI. The company operates from an NYC office.
This is one of the clearest signs that enterprise agents are becoming operational systems.
Nobody needs sophisticated access-control infrastructure for a chatbot that only writes marketing copy.
They need it when software can change the business.
Prompts Are Not Security Policies
A dangerous architecture says:
“Do not approve payments above $5,000.”
A better architecture prevents the agent from executing that action without an external approval.
Those are very different systems.
The first depends on model behavior.
The second depends on control infrastructure.
As autonomy increases, enterprises will need more of the second.
Finding #6: The Most Advanced Agent Platforms Are Starting to Look Like Organizations
Most AI products still begin with a user.
The user asks for something.
The system responds.
General Intelligence Company is exploring a more aggressive model.
The New York startup is building Cofounder, a system of specialized agents intended to automate company operations across areas including engineering, marketing, support, and other business functions. The company raised an $8.7 million seed round led by Union Square Ventures in 2025.
The important idea is organizational.
Instead of asking:
“What can one agent do?”
The company is effectively asking:
“How should many agents be organized so that a business can operate?”
That requires hierarchy.
It requires shared context.
It requires task assignment.
It requires recurring work.
It requires different permissions for different agents.
It requires handoffs.
It requires goals.
At that point, the software is starting to resemble a company operating system.
Strange Loop Shows What an Industry-Specific Agent OS Could Look Like
New York-based Strange Loop is taking a related approach inside institutional finance.
Its platform combines purpose-built product interfaces, financial agents, and infrastructure that can be deployed in a customer’s cloud or on-premises environment. The company emphasizes security, compliance, monitoring, and adaptation to each firm’s internal processes.
This may be especially relevant to New York.
The city’s biggest autonomous-enterprise opportunities may not come from one horizontal agent platform replacing everything.
They may come from deeply specialized operating systems.
A hedge fund could have an agent operating layer designed around research, positions, compliance, risk, and reconciliation.
An insurer could have one designed around underwriting, claims, policy servicing, and regulatory controls.
A law firm could have one built around matters, documents, conflicts, research, deadlines, billing, and partner approvals.
The operating system could become vertical.
Why New York Is a Natural Market for Agent Operating Systems
New York’s advantage is not that it has more foundation-model laboratories than every other city.
Its advantage is demand.
NYCEDC describes a city with more than 2,000 AI startups, 25,000 technology-enabled startups, 40,000-plus workers with AI skills, and more than 1,200 active venture firms.
More important, many of the industries where AI adoption is already moving fastest are unusually important to New York.
The NYC Comptroller reported in 2026 that adoption is sharpest in finance, information, and professional services. It also noted that more than half of firms in one CFO survey had invested in AI by early 2026, although most deployments remained limited to only a few business functions. Privacy and data security remained major barriers.
Those conditions favor infrastructure.
Companies want agents.
But they do not yet trust them enough to open everything.
That gap is the market.
Chart 5: Why NYC Creates Strong Demand for Agent Infrastructure
| NYC factor | Publicly reported signal | Why it matters for agent infrastructure |
| AI startups | 2,000+ | Creates builders and early customers |
| Tech-enabled startups | 25,000+ | Large software ecosystem |
| AI-skilled metro workers | 40,000+ | Technical talent |
| Active venture firms | 1,200+ | Capital access |
| AI-ready graduates, 2018–2023 | 87,000+ | Talent pipeline |
| Workflow-signal companies in our 74-company map sample | 38 | Evidence that AI is moving into processes |
| Dedicated agent-infrastructure companies in same sample | 10 | Visible local infrastructure layer |
Sources: NYCEDC and AI Atlas NYC; calculations by NYC Tech Journal.
The combination is unusual.
New York has the builders.
It also has the workflows.
The Autonomous Enterprise Will Need More Than One Agent Vendor
Many companies are currently approaching agent adoption as if they were buying another SaaS product.
That is probably too simple.
Imagine a financial-services company deploying a research agent.
The model might come from one provider.
The agent framework may come from another.
Compute may run through a cloud infrastructure provider.
A sandbox may isolate generated code.
An orchestration system may manage long-running tasks.
An enterprise context layer may provide approved information.
An MCP or tool gateway may control access to applications.
An evaluation system may test the agent before deployment.
The company’s identity system may determine which employee can authorize which action.
Its logging stack may store the resulting events.
That is an architecture.
Not an app.
Chart 6: What a Production Agent Workflow Could Actually Look Like
| Step | Infrastructure responsibility | Example |
| 1. Work arrives | Trigger / orchestration | New customer request enters CRM |
| 2. Agent identifies goal | Model + planning | Determine required actions |
| 3. Relevant context loads | Context layer | Retrieve account, policy and prior history |
| 4. Permissions are checked | Identity / governance | Confirm agent can access records |
| 5. Agent chooses tools | Tool gateway | CRM, email, browser, internal API |
| 6. Risky code runs safely | Sandbox | Execute analysis in isolated environment |
| 7. Workflow persists | Durable execution | Save progress after every important step |
| 8. Agent reaches exception | Policy engine | Flag amount above allowed threshold |
| 9. Human approves | Human-control layer | Manager reviews recommendation |
| 10. Agent resumes | Orchestration | Continue from stored state |
| 11. Result is checked | Evaluation | Validate output against business rules |
| 12. Everything is recorded | Audit / observability | Preserve actions, inputs, outputs and approvals |
The AI model is only one row.
That is the central infrastructure lesson.
The Agent Operating System Will Probably Be Composable
Enterprises should be cautious about any vendor claiming it will own the entire agent stack.
The market is changing too quickly.
Models are changing.
Agent frameworks are changing.
MCP is changing how tools are exposed.
Browser-use systems are improving.
Identity vendors are adding agent controls.
Cloud companies are adding agent services.
Data platforms are adding memory and retrieval.
Observability companies are adding evaluations.
The more sensible architecture in 2026 is usually composable.
A company should be able to replace a model without rebuilding every workflow.
It should be able to change an evaluation system without changing the business logic.
It should be able to add another tool while keeping the permission layer.
The enterprise should own the workflow even when vendors change underneath it.
Model Independence Will Become a Strategic Requirement
This is especially important because model leadership changes quickly.
A workflow designed specifically around one model may perform brilliantly today and become unnecessarily expensive six months later.
The operating layer should therefore separate business logic from model selection where possible.
Think about a procurement agent.
Its business process might say:
Retrieve supplier history.
Check inventory need.
Compare pricing.
Review contractual rules.
Prepare a recommendation.
Request approval above a threshold.
Issue the purchase order.
Those rules belong to the business.
Whether one individual reasoning step uses OpenAI, Anthropic, Google, an open model, or another provider should ideally remain replaceable.
That protects the company.
Human Approval Should Be a Product Feature, Not an Emergency Brake
Many enterprise AI projects claim to have a “human in the loop.”
That phrase is too vague.
A useful system defines exactly when a person becomes involved.
A $12 refund might proceed automatically.
A $1,200 refund might require approval.
A contract clause with no meaningful change may pass.
A change to liability language may go to legal counsel.
A marketing agent may publish to an internal knowledge base automatically but require a person before posting to the company’s public social account.
Human control should therefore be designed at the action level.
Build an Autonomy Ladder
Instead of asking whether a workflow should be autonomous, companies should decide how much autonomy each action deserves.
| Autonomy level | Agent behavior | Suitable example |
| Level 0 | Observe only | Summarize records |
| Level 1 | Recommend | Suggest next action |
| Level 2 | Draft | Prepare email or system update |
| Level 3 | Execute with approval | Submit after manager confirmation |
| Level 4 | Execute within limits | Approve small refund automatically |
| Level 5 | Full workflow autonomy | Complete routine low-risk process |
This approach makes deployment easier.
A company does not have to decide between “AI assistant” and “fully autonomous agent.”
It can move individual actions upward when evidence shows they are safe.
Reliability Will Become a Board-Level Metric
Companies currently measure AI adoption with numbers such as users, prompts, licenses, and hours saved.
Those metrics become weak once agents perform work.
An autonomous system should be measured like an operating process.
Did it finish?
Was the outcome correct?
How often did a person need to rescue it?
How much did one completed workflow cost?
How many actions had to be reversed?
Did it violate a policy?
How often did it stall?
How long did exceptions remain unresolved?
These questions are much closer to operations than software usage.
The Agent KPI Dashboard Every Enterprise Should Build
| KPI | What it tells management |
| Successful workflow completion rate | Whether the agent actually finishes work |
| Human intervention rate | How dependent the workflow remains on people |
| Exception rate | How often unusual cases appear |
| Action reversal rate | How often completed agent actions must be undone |
| Policy violation rate | Whether autonomy is staying inside controls |
| Mean time to recover | How quickly failures are resolved |
| Cost per completed workflow | Whether automation economics make sense |
| Average workflow duration | Whether the agent improves throughput |
| Approval latency | Whether human checkpoints create bottlenecks |
| Tool failure rate | Which systems make automation unreliable |
| Escalation accuracy | Whether the agent knows when it should stop |
| Audit completeness | Whether important actions can be reconstructed |
The key unit is completed work.
Not prompts.
Not tokens.
Not chatbot sessions.
What New York Companies Should Buy and What They Should Build
The correct answer will differ by organization, but one principle is broadly useful:
Buy infrastructure. Own business logic.
A bank does not need to build its own sandbox technology.
A retailer probably does not need to invent a durable task engine.
A law firm should not create an identity system from scratch.
Those are infrastructure problems that specialized companies can solve.
However, the organization should understand and control its own workflow rules.
It should know what “complete” means.
It should define approval thresholds.
It should decide which records are authoritative.
It should determine what happens during an exception.
That knowledge is the company’s operating advantage.
Outsourcing all of it to a generic AI vendor can create a different form of lock-in.
Start With One Workflow, Not an Enterprise Agent Strategy
The phrase “autonomous enterprise” sounds enormous.
The first implementation should usually be small.
Choose one workflow with a clear beginning and end.
Good candidates often have several characteristics.
The work happens frequently.
The rules are reasonably understandable.
The process touches several systems.
Employees spend significant time moving information rather than applying unique judgment.
Errors can be detected.
There is a clear person responsible for the workflow.
Success can be measured.
An accounts-receivable exception workflow may be better than “build an AI finance employee.”
A certificate-of-insurance workflow may be better than “automate insurance.”
A proposal-review workflow may be better than “deploy a sales agent.”
Narrow scope makes the infrastructure visible.
A Practical 90-Day Agent Operating System Plan
Days 1–30: Map the Work Before Choosing the Agent
The first month should focus on the process.
Document every important step in the workflow.
Identify which systems are touched.
Record where employees make decisions.
Mark actions that change money, customer records, contracts, permissions, public content, or regulated information.
Determine where the process usually breaks.
The output should be a workflow map, not a vendor shortlist.
Days 31–60: Build the Control Layer
Once the process is understood, decide what the agent is allowed to do.
Create permissions by action.
Choose which steps require human approval.
Establish a sandbox if generated code or uncertain actions will run.
Add logging.
Add durable state so long workflows can recover.
Define the minimum context the agent needs.
Create test cases from real historical work.
Only then should the company increase autonomy.
Days 61–90: Run the Agent Against Real Exceptions
The final month should not focus on perfect examples.
Give the system messy cases.
Missing information.
Incorrect documents.
Duplicate records.
Slow APIs.
Conflicting instructions.
Unusual customers.
Expired credentials.
Human approvals that arrive late.
The goal is to discover where autonomy breaks before those failures happen at scale.
The Biggest Mistake Will Be Measuring the Demo Instead of the System
Most agent demos happen under ideal conditions.
The model receives the correct information.
The integration works.
The webpage loads.
The API responds.
The task is familiar.
Nobody interrupts the process.
Businesses do not operate that way.
Production systems fail in the spaces between the happy paths.
That is why the winners in agent infrastructure may not be the companies producing the most impressive 30-second demonstrations.
They may be the ones making the boring parts work.
Retries.
Permissions.
Checkpoints.
Logs.
Approvals.
Isolation.
Identity.
Versioning.
Recovery.
Those features rarely go viral.
They make enterprises run.
Security Changes When AI Can Take Action
A traditional AI security incident might leak information.
An agent security incident can change something.
That difference is enormous.
An attacker who manipulates a chatbot may receive an incorrect answer.
An attacker who manipulates an autonomous agent may cause an email to be sent, a record to be altered, code to execute, a customer account to change, or money to move.
The operating layer therefore needs to assume that the model itself cannot be treated as the final security boundary.
Every important action needs external controls.
Agent Memory Needs Governance Too
Memory sounds like a convenience feature.
Inside an enterprise, it can become a security issue.
What should the agent remember?
For how long?
Who can inspect the memory?
Can one employee’s interaction affect another employee’s agent?
What happens when a customer asks for data to be removed?
How are incorrect memories corrected?
Who decides which memory is authoritative?
These questions show why the context and governance layers may eventually merge.
Persistent agents cannot have unlimited memory without enterprise rules around that memory.
New York Could Become Strongest Where Infrastructure Meets Regulated Work
This is where New York’s industry mix may become a major advantage.
The city does not only contain technology customers.
It contains difficult technology customers.
Financial institutions care about access control.
Insurance companies care about auditable decisions.
Healthcare organizations care about sensitive information.
Law firms care about confidentiality.
Public companies care about internal controls.
These buyers force agent infrastructure to mature.
A product that works inside a small marketing startup may fail inside a bank.
A company that survives the second environment may build something far more defensible.
The Infrastructure Market Could Move From Tools to Control Planes
Today the market still looks fragmented.
One vendor offers execution.
Another offers orchestration.
Another offers governance.
Another offers context.
Another offers observability.
Over time, several of these categories may collapse into broader control planes.
An enterprise may eventually open one console and see every deployed agent.
The company could see what each agent is allowed to do.
Which model it uses.
Which tools it can call.
Which data it can access.
How much it costs.
Which workflows are running.
Which ones failed.
Which approvals are waiting.
Which policies apply.
Which actions were completed today.
That would be much closer to a true AI agent operating system.
The Most Valuable Asset May Become the Enterprise Workflow Graph
The deeper strategic opportunity may not be the model or even the agent.
It may be the structured map of how the company works.
Imagine an enterprise system that understands:
Which teams exist.
Which applications they use.
Which records belong to which customers.
Which decisions require approval.
Which processes depend on other processes.
Which employee owns an exception.
Which contracts govern a transaction.
Which actions are reversible.
Which actions are high risk.
Which workflows happen every day.
That information is currently scattered across employee experience, documentation, SaaS configurations, email, policy documents, databases, and organizational habits.
Agents force companies to make it explicit.
That creates something new: a machine-readable operating model of the enterprise.
Once that exists, automation becomes much easier.
The Bigger Story: Software Is Moving From a Tool Employees Operate to a System That Operates Work
For most of the history of enterprise software, people have served as the integration layer.
An employee reads an email.
They understand what it means.
They open another application.
They copy information.
They make a decision.
They update the system.
They tell another employee.
Software stores the information, but the person moves the process forward.
AI agents challenge that model.
When software begins moving the process itself, the company needs infrastructure to replace the coordination that humans previously provided.
That is the real meaning of an agent operating system.
It is not a prettier chatbot.
It is the machinery that allows software to participate safely in the operation of the enterprise.
Five Things We Expect to Happen Next
Agent Infrastructure Will Become Less Visible to End Users
Employees will care less about which orchestration engine runs underneath their agent.
They will simply expect the workflow to finish.
Infrastructure will increasingly disappear behind business applications in the same way most employees do not know which database powers their CRM.
Governance Will Move Closer to Execution
Security teams will stop treating agent governance as a policy document that sits above the technology.
Permissions, approvals, and limits will become executable controls inside the workflow.
An agent will not merely be told what it should not do.
The infrastructure will prevent it.
Vertical Agent Operating Systems Will Grow Quickly in New York
Finance, law, insurance, healthcare, real estate, advertising, and commerce contain very different workflows.
A generic orchestration engine may power all of them, but the business layer above it will become increasingly specialized.
New York’s industry density makes the city a strong testing ground for these vertical systems.
Companies Will Manage Agents More Like Digital Employees
Enterprises may eventually maintain an inventory containing every production agent.
Each agent could have an owner, role, permissions, approved tools, approved data, model configuration, cost budget, performance history, and escalation path.
That would make agent management look less like buying software and more like operating a workforce.
Autonomy Will Increase One Permission at a Time
The transition will not happen when a CEO announces that the company is autonomous.
It will happen quietly.
One agent gets permission to draft.
Then update.
Then execute a low-risk action.
Then handle routine exceptions.
Then coordinate another agent.
Autonomy will accumulate inside workflows.
What New York Business Leaders Should Do Right Now
Do not begin by asking how many agents the company should deploy.
Find one valuable workflow.
Map it in detail.
Identify the systems involved.
Define which information is authoritative.
Decide what the agent can read.
Decide what it can change.
Create explicit approval rules.
Make every meaningful action observable.
Make long-running work recoverable.
Test failures before expanding permissions.
Then measure completed work.
If the agent performs reliably, increase autonomy gradually.
That process may sound slower than launching a chatbot across the entire company.
It is actually the faster route to useful autonomy because it produces infrastructure that can be reused.
The second agent becomes easier.
So does the third.
Eventually, the organization stops building isolated AI pilots.
It starts building an operating layer.
Conclusion: The Most Important AI Companies May Be the Ones Building What Agents Stand On
The autonomous enterprise will not arrive because one model becomes intelligent enough.
Intelligence is only part of the problem.
Businesses also need control.
They need context.
They need computers agents can safely use.
They need orchestration.
They need durable execution.
They need permissions.
They need monitoring.
They need memory.
They need human approval.
They need a record explaining what happened.
Our September 2026 NYC snapshot shows the beginnings of that market. Dedicated agent infrastructure already represents 13.5% of the 74-company AI sample we analyzed, while more than half of the companies in the broader map carry a workflow signal. The six infrastructure companies with explicit latest-round dollar amounts in our sample represented $156.5 million in disclosed rounds, with most of that capital concentrated in Series A companies.
The numbers are early, and the categories will change.
But the direction is becoming clearer.
Enterprise AI is moving from answering questions to performing work.
When software performs work, somebody has to manage how that work happens.
New York startups are increasingly building that management layer.
That may become one of the most important software markets of the agentic AI era.
