How AI agents can log calls and next steps in your CRM

AI agent CRM call logging works best in three steps: the agent reads the transcript and drafts a structured record with one outcome from a fixed list and a dated next step, the rep confirms it, and a narrow tool writes it to the CRM. The tool checks every field, links the right contact, and keys the record on the call’s ID.

What a logged call holds, in any CRM

Every CRM stores a call as an activity on a contact, but the fields and units differ. Salesforce keeps calls as Tasks (Task object reference); HubSpot keeps them as call engagements (Calls API guide). Two examples show why the agent should never write raw fields itself:

What the record needs	Salesforce Task	HubSpot call
The person	Name (WhoId): a Contact or Lead	An association to a contact
The account or deal	Related To (WhatId)	An association to a company or deal
Direction	Call Type: Inbound, Internal or Outbound	hs_call_direction: INBOUND or OUTBOUND
Duration	Call Duration, in seconds	hs_call_duration, in milliseconds
Outcome	Call Result: text, up to 255 characters	hs_call_disposition: the outcome’s internal ID
Notes	Comments (Description)	hs_call_body
When	CompletedDateTime, set when the Task is saved as closed	hs_timestamp, required; it places the call on the timeline

A model asked to log a 5-minute call could send 300 where HubSpot needs 300,000, or type “Left VM” where the CRM expects an ID. HubSpot’s default outcomes are Busy, Connected, Left live message, Left voicemail, No answer and Wrong number, each stored by ID. Salesforce stores whatever text it is given. So the agent should pick from your outcome names, and the tool should translate them into each CRM’s fields in code.

Give the agent one narrow tool

OWASP’s Excessive Agency guidance starts with fewer tools and fewer permissions. For call logging, that means one tool that logs a call, not general access to edit any record. In MCP terms, the tool’s input schema lists the fields and the allowed outcomes, and the server checks them (MCP tools specification):

{
  "name": "log_call",
  "arguments": {
    "call_id": "call_8f2c",
    "contact_id": "contact_1042",
    "outcome": "call_back_later",
    "duration_seconds": 312,
    "notes": "Asked about pricing for a team of 12. Budget review ends next week.",
    "next_step": { "type": "call", "due": "2026-10-22" }
  }
}

The tool should refuse anything it cannot verify, and say why. The MCP specification calls these tool execution errors: results marked as errors, with feedback the model can use to correct and retry, such as “outcome must be one of: no_answer, left_voicemail, call_back_later”. Check at least:

1. The outcome is on your fixed list. For a list that works, see call outcomes in Salesforce.
2. The contact exists, and the user the agent acts for is allowed to edit it.
3. The numbers make sense: duration as a whole number of seconds, and a next-step date in the future.
4. The call ID is new, or the tool updates the record already logged for it.

If the tool declares an output schema, the specification requires its results to match it, so the agent gets back the CRM record ID in a known shape and can link the next step to it.

Review before write

A call record is something managers report on and account owners act on, so a person should see it before it is saved. The MCP specification says a human should always be able to deny a tool call, and that apps should show the tool’s inputs before calling the server. In practice:

• Show the draft in one view: outcome, notes, next step and the contact it will be saved to. One click confirms, and any field can be edited.
• Label AI-written text as AI-generated in the record, so readers know what a person checked.
• Treat the transcript as untrusted. OWASP’s prompt injection guidance covers instructions hidden in outside content. A caller’s words are outside content, so they can shape the summary but never change which tools run or which record is written.
• Log the confirmation: who confirmed, when, and what they changed.

Some writes can skip review once you trust them, such as a No answer outcome that the phone system itself recorded. Decide that per outcome, in writing.

Steps to set it up

1. Write your outcome list and decide which outcomes count as a connect and a conversation.
2. Map each field to your CRM, including units and outcome IDs.
3. Expose one logging tool to the agent, with the outcome as a fixed list in its input schema.
4. Validate every field in the tool, and return clear errors.
5. Show the rep the draft; write only after they confirm.
6. Key every write on the call ID, and return the CRM record ID.
7. Read 10 logged calls a week against their transcripts, and fix the prompt or the tool when they disagree.

For the CRM side in Salesforce, see how to log calls in Salesforce automatically. For the rules an agent needs when it also places calls, see guardrails for AI agents that place phone calls.

How DialSavvy handles this

Live today: recordings, transcripts and an AI summary after every conversation, with the next step ready for the rep to confirm. In early access, DialSavvy for Salesforce logs each conversation as a Task on the rep’s own user, and adds the AI summary and next steps to the same Task, marked as AI-generated. Coming: the MCP server, with tools to read summaries and set outcomes, where every outcome change is logged; plus the REST API and HubSpot and other CRMs. See the MCP page.

Start with one outcome list and one logging tool, run it with one rep for a week, and compare every record with its transcript before you widen it. To see call summaries become CRM records, book a demo.