Enterprise Agents Need More Than Tools: Identity, Connectors, and Interrupts

After building a Slack-facing agent with Vercel Eve, I started thinking about the less visible architecture around enterprise agents: who the agent acts as, how tokens are handled, and what happens when a downstream system needs a human to answer.

Introduction

After building the first Eve workflow, I kept coming back to the connector layer.

The demo itself was small. A Slack message became a LinkedIn draft. The draft went through a lint check. I approved the publish step in Slack. Eve wrote the final result to Notion.

That was enough to make the loop concrete, but it also exposed a second layer that feels just as important for enterprise systems: identity.

It is easy to say an agent has access to a tool. In practice, that sentence hides several questions.

Who invoked the agent? Which runtime is executing the workflow? Which named agent is performing the action? Is the downstream system using the human’s OAuth token or an integration user? If a downstream system needs more input, where does that question show up?

Those questions are where agent demos start to look like enterprise architecture.

Connectors Are More Than Tool Access

When people talk about agents, the conversation often moves quickly to tools.

Can the agent query Salesforce? Can it write to Notion? Can it open a Jira ticket? Can it call a warehouse? Can it invoke an internal API?

Those are important questions, but they are incomplete.

The more important version is:

Can the agent call the right capability
with the right identity
through the right permission boundary
and leave behind a trace we can reason about later?

That is why the connector layer matters.

In the Eve project, the Notion connection used Vercel Connect. The first time the workflow needed Notion, the agent could park, ask me to authorize, resume after the OAuth flow completed, and continue the original run.

That behavior was easy to treat as setup friction in the moment. Looking back, it was one of the most useful parts of the experiment.

There was a difference between the project having a Notion connector configured and me, as the Slack user, being authorized to use Notion through that connector.

That same distinction shows up quickly in enterprise systems.

The Four Identity Layers

The mental model I ended up with has four identity layers.

Human identity
The person who invoked the agent or responded to the prompt.

Runtime identity
The deployed system executing the workflow.

Agent identity
The named agent or workflow performing the work.

Downstream authority
The identity the downstream system uses to authorize the action.

In the Eve demo:

Human identity: me in Slack
Runtime identity: the Vercel deployment
Agent identity: the Eve content assistant
Downstream authority: my Notion authorization

That last line is where the architecture can vary.

For a system like Salesforce, the downstream authority might be a user-delegated OAuth token:

Taylor in Slack
-> Eve workflow
-> Salesforce using Taylor's OAuth token

Or it might be an integration user:

Taylor in Slack
-> Eve workflow
-> Salesforce using an enterprise integration user

Both patterns can be valid. They create different control problems.

With user-delegated OAuth, Salesforce can enforce the user’s existing permissions. That tends to be cleaner for audit and least privilege.

With an integration user, the agent may have a broader operational identity inside Salesforce. That can be useful for controlled backend workflows, but it puts more responsibility on the harness. The agent has to enforce what the human is allowed to request, because Salesforce may only see the integration user.

How Salesforce Would Be Queried

Vercel Connect handles authorization and token management. The query itself belongs to the capability layer we expose to the agent.

For Salesforce, I would expect one of a few patterns:

Eve -> Salesforce MCP server -> Salesforce APIs
Eve -> OpenAPI connection -> Salesforce REST APIs
Eve -> custom tool -> Salesforce SDK / REST / SOQL
Eve -> Salesforce agent endpoint -> Salesforce-native agent or flow

The connector supplies the token. The tool, MCP server, OpenAPI connection, or custom integration performs the actual query.

For example, if a user asks:

Can you prep me for my Acme renewal call?

The Slack-facing agent might infer that this is a CRM task. Then it could call a Salesforce capability with a structured request:

{
  "task": "prepare_account_brief",
  "account_name": "Acme",
  "intent": "renewal_call_prep",
  "constraints": {
    "read_only": true
  },
  "needed_outputs": [
    "open_opportunities",
    "renewal_risks",
    "recent_cases",
    "talking_points"
  ]
}

The model can infer the need for Salesforce because the harness advertises Salesforce as a capability. The schema and policy code decide whether the request is valid enough to execute.

That distinction is important. I would not want a broad, vague “Salesforce access” tool. I would want a defined set of Salesforce capabilities with input schemas, output schemas, auth mode, risk level, approval policy, and eval coverage.

Where The Inference Happens

There are two places inference can happen.

The Slack-facing agent can infer that the user’s request belongs to Salesforce:

Slack request
-> Eve interprets the intent
-> Eve builds a structured Salesforce task
-> Eve calls the Salesforce capability

The Salesforce side can also perform domain-specific inference:

Structured Salesforce task
-> Salesforce agent/action/flow decides which records matter
-> Salesforce returns a structured result

That split feels right to me.

The outer agent should understand the human workflow, the Slack context, the approval expectations, and the enterprise capability registry. Salesforce should understand Salesforce.

For a mature enterprise environment, I would expect both layers to have some kind of registry.

The outer registry might know:

Capability: Salesforce account brief
Owner: Revenue systems
Auth mode: user OAuth
Risk: read-only
Input schema: account, intent, constraints
Output schema: summary, risks, next actions
Eval coverage: CRM routing and no-write behavior

The Salesforce-side registry might know:

Agent/action: renewal risk analyst
Agent/action: pipeline hygiene reviewer
Agent/action: account update proposer
Agent/action: follow-up drafter

That keeps the Slack-facing agent from needing to know every Salesforce-native detail. It only needs to know how to ask Salesforce for bounded work.

The Nested Human Input Problem

The most interesting question came up when thinking about Salesforce agents.

What if the Salesforce-side agent starts its own execution and then needs a human to answer something?

For example:

User: Prep me for my Acme renewal call.

The Slack-facing agent delegates to Salesforce. The Salesforce-side agent finds two relevant opportunities and needs the user to choose one before it can continue.

The human is in Slack. The Salesforce agent is somewhere downstream. The outer Eve workflow is waiting on the Salesforce result.

That requires interrupt propagation.

The Salesforce-side agent would need to return something like:

{
  "status": "input_required",
  "prompt": "Which opportunity should I use?",
  "options": [
    { "id": "opp_1", "label": "Acme Renewal FY26" },
    { "id": "opp_2", "label": "Acme Expansion" }
  ],
  "resume_handle": "opaque-salesforce-run-token"
}

Then the Slack-facing agent would translate that into a Slack prompt:

Which opportunity should I use?

[Acme Renewal FY26]
[Acme Expansion]

After the human answers, the outer agent sends the response back to Salesforce:

{
  "resume_handle": "opaque-salesforce-run-token",
  "response": {
    "option_id": "opp_1"
  }
}

Salesforce resumes its run, completes the task, and returns the final result to the outer agent. The outer agent summarizes the result back in Slack.

That flow is more complicated than a simple tool call, but it is probably common in real enterprise workflows.

The downstream system may need clarification, approval, disambiguation, or missing context. The user may only be available through Slack or Teams. The orchestration layer has to carry that interruption across system boundaries without losing identity, state, or auditability.

Who Should Own The Human Surface?

My bias is that the outer agent should own the user surface.

If the workflow starts in Slack, the human input should usually come back through Slack. If the workflow starts in Teams, it should come back through Teams.

That does not mean the outer agent owns every decision. Salesforce can still decide that it needs the user to choose an opportunity. The Salesforce-side agent can still generate the prompt and options. The outer agent owns the translation back to the human surface and the resume call afterward.

The split becomes:

Salesforce owns the domain pause.
Eve owns the user-surface pause.

That is the kind of boundary I would want to be explicit about in an enterprise architecture.

Otherwise, you can end up with multiple systems trying to own the human interaction at the same time. One system asks in Slack. Another sends an email. Another opens an approval in Salesforce. The user experiences one workflow as three disconnected prompts.

What This Opens Up

If this layer is designed well, it opens up a useful pattern.

A Slack-facing agent can become the outer coordination surface. It can understand the user’s request, choose the right enterprise capability, pass a structured task to a domain system, surface any human input back to the same thread, and continue the workflow after the answer.

The downstream systems can keep their own domain logic.

Salesforce can understand accounts, opportunities, renewals, cases, and flows. Jira can understand issues and projects. ServiceNow can understand incidents and approvals. A warehouse agent can understand metrics and query plans.

The outer loop does not have to absorb every domain.

It needs a safe way to delegate, pause, resume, and audit.

What I Would Look For In A Platform

This is where my evaluation criteria would move beyond model quality.

For enterprise agent infrastructure, I would want to know:

How are human identities mapped across channels?
How are user tokens stored and refreshed?
Can a connector use user OAuth or an integration user?
Can the agent park while OAuth completes?
Can a downstream system request human input?
Can that request surface back to Slack or Teams?
Can the downstream run resume after the human responds?
Are resume handles opaque and protected?
Can we trace the full path across systems?
Can we write evals against the orchestration path?

These questions are dry, but they are the ones that determine whether an agent can survive outside a demo.

What I Am Taking Away

The first Eve post was about the managed loop. This one is about what the loop has to carry.

For enterprise workflows, the loop has to carry more than prompts and tool calls. It has to carry identity, authorization state, approval state, downstream interruptions, and enough metadata to audit what happened later.

That is why connectors matter.

They are part of the control plane around the agent. They help determine who the agent is acting for, what the agent is allowed to do, and how the workflow resumes when a system needs the human again.

The more I think about this, the more I think the enterprise agent stack has to be evaluated at the boundaries:

human to agent
agent to tool
agent to downstream agent
downstream agent back to human
human response back into the run

Those boundaries are where the interesting failures will happen.

The agent loop matters. The harness matters. But the connectors, identity model, and interrupt protocol may be what decide whether these systems become usable in real enterprise workflows.