Fin AI MCP tool calling is taking too long - how to reduce this latency?

We’re building a personalized onboarding experience using a Fin Procedure and two custom Data Connectors.

The customer first receives this static welcome message through an Intercom Workflow:

Hi, I’m an agent designed to help guide you through the product. I have a personalized suggestion for you. Would now be a good time to share it?

When the customer responds with “Yes please,” Fin triggers the Procedure, retrieves their recent product activity and onboarding progress, and recommends one relevant action.

Live test environment

The experience can be tested here:

https://twentycrm.demo.autoplay.ai/

Suggested reproduction steps:

1. Open the demo.
2. Navigate between a few product areas, such as Companies, People, and Notes.
3. Open the Intercom Messenger.
4. Start a new conversation.
5. Wait for the personalized-suggestion welcome message.
6. Reply “Yes please.”
7. Measure from Fin’s “I’ll look into that for you right away!” message until the personalized recommendation begins.

Current Procedure structure

The Procedure currently contains the following steps:

1. Interpret the customer’s latest reply.
2. Call Get live user activity.
3. Call Get onboarding context.
4. Compose and send one personalized recommendation.
5. If the customer explicitly accepts an in-app walkthrough, enter a separate conditional path and call Guide next step.
6. Continue helping with the agreed action through concise follow-up messages.

Visual guidance is deferred until the customer explicitly opts in. At that point, we call only Guide next step, which resolves and launches the walkthrough for the current onboarding milestone.

Therefore, the initial personalized response now contains exactly two Data Connector calls.

Trigger definition

Use when a customer accepts an immediately preceding offer of a personalized suggestion, or asks for personalized setup guidance, progress, their next best action, or help continuing when stuck. Do not use for unrelated support or human requests.

Current Procedure instructions

Step 1: Interpret the reply

Interpret the user’s latest reply using the immediately preceding exchange.
- A “yes” to the welcome message accepts a personalized suggestion. It does not consent to launching an in-app guide.
- A “yes” to an explicit offer to show the agreed action in the product consents to launching that guide.
- If the user asks a different question, answer that question rather than forcing the earlier recommendation.
- Reuse connector results already available in this Procedure unless the user reports meaningful new activity, completion, or a changed task.

Step 2: Retrieve recent activity

For a new personalized recommendation, call:
@Get live user activity – Autoplay-live
Use the result to understand the user’s meaningful recent activity and current product area. Do not merely repeat an event name or infer their intention.

The number of returned activities is fixed at 10.

Step 3: Retrieve onboarding context

After the activity call completes, call:
@Get onboarding context – Autoplay-live
Use the result to identify the single most relevant incomplete milestone. Do not recommend something complete or already in progress.

Step 4: Compose the recommendation

Combine the activity and onboarding context into one personalized recommendation.
- Begin with one meaningful, evidence-backed observation. Use natural first-person language such as “I can see you’ve…” when the activity is explicit, or “It looks like…” when it is less conclusive.
- Recommend exactly one concrete action.
- Naturally explain what that action will enable or why it matters for this user.
- Keep the entire response to 50 words or fewer where practical.
- End with one specific, low-effort offer connected to the action.
When visual guidance would be appropriate, end with:
“I can walk you through that in the product if a guide is available. Want me to?”
Do not claim a guide exists yet. End the turn after asking the question.

Step 5: Conditional visual-guidance path

Use this step only when the immediately preceding agent message explicitly offered an in-app guide for the agreed action and the user accepted that offer. Otherwise, skip this step.
Call once:
@Guide next step – Autoplay-live
Do not call the activity connector, onboarding connector, or tour-list connector before launching. The agreed action and onboarding context are already available.
- If launched is true, say: “The walkthrough should appear shortly. Can you see the first step?”
- If no matching tour is available, do not claim anything launched. Give the smallest useful written instruction for the same action and end with one concrete check-in question.
- If the result is uncertain or unsuccessful, do not retry automatically or expose tool details. Continue with one grounded written instruction.

Conversation rules

- The user’s current message always takes priority.
- Ground product navigation, controls, permissions, progress, and capabilities in approved product knowledge or current tool data.
- Never invent a route, menu name, access requirement, activity, intention, or completed action.
- Never say the user is “in onboarding” or expose internal stages, workflows, events, identifiers, tools, or recommendation logic.
- Address one immediate action at a time.
- Avoid standalone praise and generic filler.
- Do not use headings such as “Next”, “Why”, “Recommendation”, or “Benefit”.
- End every active assistance reply with exactly one specific question tied to the current action or next feasible milestone.
- Never end with “Anything else I can help you with?”, “Let me know”, or another open-ended close.

Connector latency

We tested the MCP tools independently against one of our busiest users. Their warm response times are approximately:

• get_live_user_activity: 0.9 seconds
• get_onboarding_context: 1.2 seconds
• guide_next_step: 1.0 second

Only the first two are now called before the initial personalized recommendation, giving us approximately 2.1 seconds of raw MCP latency.

Observed Fin execution

The Fin debugger shows three distinct reasoning phases:

1. Fin interprets the consent and calls Get live user activity.
2. After that blocking call completes, Fin resumes, reasons again, and calls Get onboarding context.
3. After the second call completes, Fin resumes again and formulates the personalized response.

Timing observed

Our typical result is approximately 15–16 seconds between:

I’ll look into that for you right away!

and the personalized recommendation.

The timing varies, but reducing the Procedure instructions and removing the two tour-discovery calls did not create a meaningful improvement.

Questions

Is this latency expected when a Fin Procedure contains two sequential blocking Data Connector calls?

More specifically:

1. Does every blocking connector call necessarily create a separate Fin reasoning and formatting cycle?
2. Can two independent Data Connector calls run concurrently within a Procedure?
3. Is there a supported way to retrieve both connector results before Fin performs its next reasoning pass?
4. Does the amount of connector response data materially affect the time Fin spends processing a successful call, even when the API itself responds in under one second?
5. Are there any additional Procedure-design techniques for reducing time to the first meaningful response?
6. Is there a typical or expected latency range for a Procedure with two custom Data Connector calls?

The personalized response quality is good, but we’re trying to make this customer-facing and the current 15–22 second delay after the filler message feels too slow for a conversational onboarding experience.