Your Pod agents don't just read your data and summarize it back to you — they act on it. An agent can draft an email to a stalled prospect, build a slide for tomorrow's QBR, push a new close date into HubSpot, or create a follow-up task after a discovery call. The more tools your agent is connected to, the more of your day-to-day work it can actually move forward on your behalf.
This is where agents stop being "another place to ask questions" and start being a real force multiplier. Insights and answers are useful, but the time-consuming part of a seller's day is the work that comes after the insight — the CRM update, the follow-up email, the prep deck, the task list. When your agents do that work in the background, you get leverage: more pipeline moved per hour, fewer things falling through the cracks, and more time for the parts of the job that actually need you in the room.
For anything that changes data in one of your connected tools, Pod pauses and asks you first. Every action the agent wants to take shows up as an approval request with the exact details of what it plans to do. Nothing is written, sent, or created until you approve. That way you get the leverage of autonomous work without giving up control of what lands in your systems.
This article covers what an agent action is, where approval requests show up, how to manage them, and what to do if one fails.
What is an agent action?
An agent action is a single step your agent wants to take in one of your connected tools. Typical examples include:
Drafting an email to a prospect and saving it as a draft in your inbox.
Creating or updating a slide deck for an upcoming meeting.
Updating a CRM field like Close Date, Stage, or Next Step on a deal.
Logging a call, creating a follow-up task, or adding a note to a record.
Pulling a document from a knowledge base and attaching it to an account.
Pod ships with a core set of tools (for example, HubSpot), and your workspace can extend that set by connecting additional MCP servers. An MCP server is how a third-party product exposes its tools to your agents — once a server is connected, the tools it offers (writing to your email, editing a slide deck, updating a support ticket, and so on) become available for your agents to propose actions against.
Whichever tool the action uses, the workflow is the same: the agent proposes the action, you see exactly what it wants to do, and you decide whether it runs.
Where approval requests appear
Approval requests surface in the places you're already working with your agents:
Inside a live chat with the agent. When the agent decides it wants to take an action, it pauses the conversation and adds an approval card to the thread right after its reply. This works the same in the Pod web app and in the Chrome Extension.
On Agent Feed cards for triggered runs. When an automation launches an agent on your behalf, any actions it proposes show up on the matching card in the Agent Feed. This surface is available in the Pod web app.
If a triggered run is also delivered to Slack, the Slack message links you back to Pod — approvals are always resolved in Pod, never inside Slack.
Manage an action in chat
An action card shows up inline, labeled like Update Deal Stage in HubSpot, with Approve and Reject buttons on the right.
From the chat:
Click the card to expand it and see the full Parameters the agent wants to use.
Click Approve to let the action run, or Reject to block it.
Watch the status badge update in place. The card will show Executing while the action runs, then Executed when it succeeds.
Continue the conversation. When you type your next prompt, the agent's next turn will take your approvals and rejections into account.
You can open multiple cards and review them in any order. You don't have to resolve them in sequence.
Manage actions from the Agent Feed
For triggered runs, the Agent Feed card gives you a compact way to resolve actions without opening the full run:
If there are one or two pending actions, each appears directly on the card with its own Approve and Reject buttons.
The feed buttons use a brief hold to confirm — press and hold for a moment so a stray click on a busy feed does not approve or reject something by accident.
If there are more than two pending actions, the card shows a Pending badge and a Review actions button that opens the full run where every action can be reviewed in detail.
Once you've resolved the actions on a card, the card shows a green N actions resolved badge so you can tell at a glance that there's nothing left to do.
Action statuses, explained
An action moves through a short set of statuses as you work with it:
Pending — The agent has proposed this action and is waiting on you.
Executing — You approved it; Pod is running it against the connected tool.
Executed — The action ran successfully.
Failed — The action ran but the connected tool rejected it. The card shows a short reason.
Rejected — You rejected the action. The agent's next turn knows not to retry it as-is.
Auto-rejected — You started a new prompt before resolving the action, so Pod closed it out for you.
Stale — The action has been Pending for more than 24 hours. It's still safe to approve, but see the next section.
What "Stale" means
Pending actions stay open indefinitely, but they get flagged as Stale after about 24 hours. When an action is stale, two things can happen at approval time:
The data the agent intended to use may no longer be the most recent state of the record.
The connection to the target tool may need to be refreshed before the action can run.
You can still approve a stale action. If the underlying data has drifted or the connection has lapsed, you'll see a Failed status with a short reason — see the next section for how to resolve the common ones.
What happens if you don't resolve an action
If you send a new prompt to the agent without first approving or rejecting the pending actions from the previous turn, Pod automatically marks them as Auto-rejected and continues the conversation. The agent can always propose new actions in a later turn.
This keeps a stale approval request from blocking you — starting a new prompt is never denied because of a forgotten approval.
When an action fails
If an action runs but fails, the card flips to Failed and shows a short reason. Here's what each reason usually means and what to do:
Unauthorized — Pod doesn't have permission to run this action in the connected tool. Check with your workspace admin or verify the integration has the right scopes.
Tool disabled — This specific tool was turned off by an admin. Ask an admin to re-enable the tool on the connected server in Settings → MCP Servers.
Server disconnected — The connected server is offline or was removed. Reconnect it in Settings → MCP Servers.
Auth expired — The credentials for the connected tool expired. Reconnect the server in Settings → MCP Servers, then approve the action again.
Invalid payload — The parameters the agent proposed didn't match what the tool expects. Ask the agent to try again in the next turn with different inputs.
Timeout — The connected tool didn't respond in time. Approve the action again; if it keeps timing out, check the service status of the connected tool.
Execution error — Something else went wrong in the connected tool. Try again; if the error persists, send us a message.
Once an action has failed, you can ask the agent in the next turn to retry the step with adjusted parameters.
Who can manage an action
Actions are owned by the person running the agent. When you run an agent manually, the pending actions belong to your run and only you can approve or reject them.
For triggered runs, the pending actions belong to the user on whose behalf the run was started. They appear on that user's Agent Feed.
If you're viewing someone else's run in a shared link, the approval controls are hidden — you'll still see the proposed parameters and status badges, but you can't change them.
💡 Need help? Send us a message via the in-app chat or email us at [email protected].
🤝 Want to talk to someone? Book a session with one of our specialists.