AI agents 101: Your mental model is probably wrong

Most agents aren’t code a developer wrote. They’re SaaS workflows anyone can assemble, running on OAuth grants nobody’s tracking.

‍

If you picture an AI agent as a program a developer wrote, running as an obvious process on a server, with an LLM tucked inside it doing the thinking, you’re picturing the exception. Most of the agents showing up inside organizations today look nothing like that. And if your mental model is wrong, your governance program will be too, because you’ll be looking for agents in places they rarely live.

‍

This piece covers the two ideas that matter most: where agents actually get built, and where the work actually runs. Neither answer is what most people expect.

‍

First, what an agent actually is

Strip away the hype and an AI agent is three things:

1. A goal, expressed in natural language. “Triage inbound support tickets.” “Summarize every sales call and update the CRM.”
2. A reasoning engine, which is a large language model deciding what to do next.
3. A set of tools the agent can use to gather information or take action: query a database, send an email, run a script, update a record.

The “agentic” part is the loop. The agent sends the goal and current context to an LLM, the LLM responds with either an answer or a request to use a tool, the agent executes that tool, appends the result to the context, and sends it all back. Repeat until the goal is met. That’s it. The loop itself is remarkably simple code. Everything interesting happens elsewhere, which is exactly the point of the next two sections.

‍

Misconception 1: Agents are software that developers build.

The default mental picture is a developer writing Python against an LLM API, wiring up tools, and deploying the result. Those agents exist. They are a small minority of what’s actually running in your organization.

‍

The most common way agents get built today is in what-you-see-is-what-you-get editors inside SaaS platforms. No code, no repo, no deploy pipeline, no IT ticket. A few flavors:

‍

Automation platforms with agentic steps. Tines, Zapier, n8n, Workato, and Make have spent years accumulating connectors and OAuth grants into your email, CRM, ticketing, file storage, and chat. Adding an “AI step” or a full agent builder to those workflows took each vendor roughly one product cycle. The result: an ops person can drag an agentic reasoning block into a workflow that already has automated access to a large share of your organization’s data. The agent didn’t earn that access. It inherited it.

‍

Agents embedded in the SaaS suites themselves. Microsoft Copilot Studio, Salesforce Agentforce, ServiceNow AI Agent Studio, Atlassian Rovo, Gemini for Google Workspace. These builders live inside platforms your employees already use all day, pre-wired to the data those platforms hold. Building an agent here feels less like software development and more like configuring a Slack workflow.

‍

Consumer-grade agent builders. ChatGPT workspace agents, OpenAI agent workflows, Zoom AI workflows, Retool, and a steady stream of newer entrants. Low friction, fast to adopt, and frequently connected to corporate accounts through OAuth.

‍

And yes, code. Developers building with agent frameworks and model APIs, plus coding agents like Claude Code and Cursor running on laptops. Real, growing, and still the smallest slice by volume.

‍

The through line: building an agent is now closer to filling out a form than shipping software. Anyone in your organization who can build a Zapier zap can build an agent. Most of them won’t ask first, and honestly, most of them won’t realize there was anything to ask about. From their perspective they just added a smarter step to an automation they already owned.

‍

Misconception 2: The intelligence runs locally.

The second bad mental model: an agent is a heavyweight process with an LLM “wrapped inside,” executing its logic on whatever machine hosts it. Look for the big obvious process, find the agent.

‍

The reality is almost the inverse. The agent process itself, wherever it lives, is a lightweight coding loop. Its job is staging: assemble the prompt, ship it out, wait, act on what comes back. The reasoning happens in the model provider’s datacenter. OpenAI, Anthropic, Google, or a cloud-hosted model endpoint. Every “thought” the agent has is a round trip across the network.

‍

The tool calls follow the same pattern. When the LLM responds with “run this tool,” the agent executes it one of two ways:

• Local tools: shell commands, file access, writing and running code on the host machine. Common for coding agents, less so for the SaaS-built majority.
• MCP servers and API connectors: programmatic actions against hosted datasets in other SaaS providers. Read the CRM, search the wiki, send the email, update the ticket. The Model Context Protocol (MCP) has become the standard way to hand an agent a menu of actions against a remote service, and each connection is typically authorized with an OAuth grant that persists long after anyone remembers creating it. Across Nudge Security’s data, employees generate an average of 88 OAuth grants each, 31 of which carry data-level permissions.

So the anatomy of a typical enterprise agent looks like this: a thin orchestration loop (often itself hosted inside a SaaS platform, not on any machine you own), reasoning outsourced to a frontier model datacenter, and actions executed against data sitting in yet other clouds. The agent isn’t a program so much as a standing set of permissions with a decision-maker attached.

‍

That last framing is the one worth internalizing. Agents are orchestrators of cloud services. The local footprint is minimal to nonexistent. There is no binary to scan, no daemon to spot in a process list, and often no machine at all.

‍

Why this makes discovery genuinely hard

If agents were developer-built software, you’d find them the way you find software: code repos, CI/CD, cloud inventory, EDR. None of those work here, because:

‍

There’s no artifact. An agent built in Copilot Studio or Zapier is a configuration inside someone else’s SaaS tenant. Nothing lands on an endpoint. Nothing shows up in your cloud account.

‍

Creation is distributed. The builders are not your engineers. They’re sales ops, HR, finance, and support, working inside tools they already had access to. There is no chokepoint to monitor.

‍

The permissions predate the agent. Because most agents are grafted onto automation platforms and SaaS suites, they piggyback on OAuth grants and integrations that were approved (or silently accumulated) years ago. Nothing new fires an alert at creation time.

‍

Platform visibility is inconsistent. Some platforms expose agent inventories through public APIs. Many of the fastest-growing ones don’t, which means API-only discovery approaches have a hard ceiling, and the agents your employees are most eager to build are often the ones you’re least able to see.

‍

The evidence is scattered across clouds. The reasoning traffic goes to a model provider. The actions hit a dozen SaaS APIs. The configuration lives in another vendor’s tenant. No single vantage point sees the whole picture.

‍

This is the Workforce Edge in miniature: decisions made by people who were never asked to think about security, using tools that already had the access they needed.

‍

The upshot: an agent inventory can’t be built by watching machines. It has to be built by watching the places agents are created and the grants that give them reach. We covered our approach in detail in AI agent discovery with Nudge Security, and how we extended it beyond the limits of platform APIs in browser-based AI agent discovery.

‍

The takeaway

Update the mental model:

• Agents are mostly clicked together in SaaS interfaces, not written by developers.
• They inherit broad data access from automation platforms and OAuth grants that already exist.
• The “agent” running anywhere is a thin loop. The intelligence lives in a model provider’s datacenter, and the actions land in other people’s clouds.
• Discovery, therefore, is not an endpoint problem or a network problem. It’s a SaaS and identity problem.

The organizations getting ahead of this aren’t the ones scanning harder. They’re the ones who accepted that agents are a new layer of business logic living across their SaaS estate, and started building an inventory from that reality, starting with a clear picture of how AI agent discovery works.

‍

Ready to see the agents your employees have already built? Start a free trial.