DEV Community: Tej Pandya

What an agent recipe actually looks like (and why it beats re-prompting every run)

Tej Pandya — Mon, 26 Oct 2026 21:47:23 +0000

Tej Pandya, founder of GrowEasy.ai

A "recipe" is the difference between a generic agent harness and a vertical one. Concretely, it is a codified procedure a specialist wrote once, which the harness executes every run instead of improvising:

recipe: qualify-inbound-call
steps:
  - load: caller_history from crm.byPhone(caller.id)
  - extract: {budget, timeline, intent} from transcript
  - check: budget >= pricing.floor          # deterministic
  - route: intent == "high" ? human_closer : nurture_sequence
verify:
  - schema: crm_entry.v2.json               # pinned output format
  - lint: no_unsupported_claims(summary)

Two parts of this are genuinely deterministic, and one is not. The routing code and the schema check are code - they run the same every time. The extract step calls a model, and served model output can vary even at temperature 0 (Thinking Machines, "Defeating Nondeterminism in LLM Inference"). So the honest claim is not "deterministic output". It is "predictable, verifiable outcomes": deterministic checks wrapped around a stochastic model. Martin Fowler's harness-engineering framing says the same - a harness increases the probability the agent gets it right.

Does it save tokens? Plausible - no re-explaining the task, fewer retries - but the recipe itself is injected context, and nobody has published a controlled with/without comparison that I could find. Anthropic reports agents use ~4x the tokens of chat and multi-agent setups ~15x, so architecture dominates token spend. Direction reasonable; magnitude unmeasured.

Does specialist procedure beat improvisation? The closest evidence: SWE-agent moved from 3.8% (a non-interactive retrieval baseline) to 12.47% of SWE-bench tasks on the same model purely through harness/interface design, and Voyager's verified skill library produced 3.3x more discoveries than recipe-less baselines in Minecraft - adjacent evidence, not a business benchmark.

One correction worth making: "generic" does not mean "no recipes". A general harness can load specialist skills. The real axis is recipes versus no recipes, not product category. Recipes rot and cover only known cases; generic wins on novelty. Write the recipe after you've done the work the hard way.

Sources: arxiv.org/abs/2405.15793 (SWE-agent), arxiv.org/abs/2305.16291 (Voyager), anthropic.com/engineering/built-multi-agent-research-system, thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference, martinfowler.com/articles/harness-engineering.html

Deploying an AI Stack for a Call-Led Business: Checklist, Smoke Test and Adoption Tracking in Python

Tej Pandya — Wed, 21 Oct 2026 05:04:19 +0000

If the agency becomes a deployment, then deploying the growth stack for a call-led firm is an engineering problem. This post sketches the steps in Python: an onboarding checklist as data, an integration smoke test, and a training tracker. It is an illustration, not a customer story, and I have no results to share.

The premise comes from watching traditional, call-led businesses fail to self-serve AI tools, and from public writing by BCG and Google on why adoption is about people and process, not software alone.

1. The deployment plan as data

DEPLOYMENT_STEPS = [
    {"step": "crm_import",      "desc": "Import existing leads into the CRM"},
    {"step": "telephony",       "desc": "Route calls through the dialer, log outcomes"},
    {"step": "whatsapp",        "desc": "Connect WhatsApp business number for follow-ups"},
    {"step": "ad_reporting",    "desc": "Send lead-source data back to the ad platform"},
    {"step": "team_training",   "desc": "Train the sales team on the daily workflow"},
]

2. A smoke test before go-live

def smoke_test(integrations: dict) -> list[str]:
    failures = []
    if not integrations.get("crm", {}).get("lead_count", 0):
        failures.append("CRM has no leads - import failed or empty")
    if not integrations.get("telephony", {}).get("test_call_logged"):
        failures.append("test call was not logged")
    if not integrations.get("whatsapp", {}).get("message_sent"):
        failures.append("WhatsApp send failed")
    if not integrations.get("ads", {}).get("last_sync_ok"):
        failures.append("ad platform sync failing")
    return failures

3. Track adoption, not setup

def adoption_report(weeks: list[dict]) -> dict:
    # weeks: [{"calls_in_dialer": 40, "calls_total": 45, ...}, ...]
    latest = weeks[-1]
    return {
        "dialer_usage": latest["calls_in_dialer"] / max(latest["calls_total"], 1),
        "followups_on_time": latest["followups_done"] / max(latest["followups_due"], 1),
        "crm_records_touched": latest["records_updated"] / max(latest["records_total"], 1),
    }

What this shows

The code is simple on purpose. The hard parts are steps 2 and 3: verifying each integration actually works for this client, and measuring whether the team uses it after you leave. Public guidance from Google says the same thing in different words - measure whether the tool helps the business, not how busy it is.

Limits

Real deployments have per-client quirks this sketch ignores: number porting, consent rules for messaging, and data cleanup. Treat this as a scaffold.

Tej Pandya, founder of GrowEasy.ai.

An Approval Queue for an AI-Supervised Agency: Routing Exceptions in Python

Tej Pandya — Tue, 20 Oct 2026 05:03:58 +0000

If an agency becomes a supervisor, the key piece of software is an approval queue: agents run routine work, and anything outside the rules waits for a person. This post sketches that in Python. It is an illustration, not a customer story, and I have no results to share.

The idea follows public advice from Google and BCG that agents handle repeatable work, while people set guardrails and review exceptions.

1. Rules the agent must follow

from dataclasses import dataclass

@dataclass
class Rules:
    max_daily_budget_change_pct: float = 10.0
    needs_legal_review: tuple = ("guarantee", "cure", "risk-free", "best in")
    allowed_channels: tuple = ("search", "email")

2. Decide: auto-run or send to a person

def route(action: dict, rules: Rules) -> str:
    text = action.get("copy", "").lower()
    if any(p in text for p in rules.needs_legal_review):
        return "legal_review"
    if action["channel"] not in rules.allowed_channels:
        return "account_manager"
    if abs(action.get("budget_change_pct", 0)) > rules.max_daily_budget_change_pct:
        return "account_manager"
    return "auto"

3. The queue and the log

import json, time
queue = []

def submit(action, rules, log="decisions.jsonl"):
    lane = route(action, rules)
    if lane != "auto":
        queue.append({"action": action, "lane": lane})
    with open(log, "a") as f:
        f.write(json.dumps({"ts": time.time(), "lane": lane,
                            "action": action.get("name")}) + "\n")
    return lane

def approve(item, who, ok, log="decisions.jsonl"):
    with open(log, "a") as f:
        f.write(json.dumps({"ts": time.time(), "approved_by": who,
                            "ok": ok, "action": item["action"].get("name")}) + "\n")

What this shows

Routine actions run. Anything with a risky claim, an odd channel or a big budget jump goes to a named person, and every decision is logged. The supervisor's job is the rules in step 1 and the judgment in step 3.

Limits

String matching will miss things. A real setup needs proper review and your own legal advice. Treat this as a sketch.

Tej Pandya, founder of GrowEasy.ai.

A Brief, a Gate and a Log: What an Agent-Era Agency Sells, in Code

Tej Pandya — Mon, 19 Oct 2026 05:05:42 +0000

If agencies sell judgment and a working system instead of hours, the product is a small "pod" setup: a brief an agent can follow, a gate a human must pass, and a log. This post sketches that in Python. It is an illustration, not a customer story, and I have no results to share.

The idea comes from public writing by BCG and Google on agent-native marketing. Both say human marketers move toward direction and oversight, and that work is checked before it goes out.

1. A brief the agent can follow

from dataclasses import dataclass, field

@dataclass
class Brief:
    goal: str
    audience: str
    must_say: list[str]
    must_not_say: list[str]
    owner: str                 # the accountable human
    learning_question: str     # what we want to learn from this run

2. A review gate

@dataclass
class Draft:
    text: str
    brief: Brief
    flags: list[str] = field(default_factory=list)

def check(draft: Draft) -> Draft:
    for phrase in draft.brief.must_not_say:
        if phrase.lower() in draft.text.lower():
            draft.flags.append(f"banned phrase: {phrase}")
    for phrase in draft.brief.must_say:
        if phrase.lower() not in draft.text.lower():
            draft.flags.append(f"missing: {phrase}")
    return draft

3. Human sign-off and a log

import json, time

def release(draft: Draft, approved_by: str, path="release_log.jsonl"):
    if draft.flags:
        raise ValueError(f"fix flags first: {draft.flags}")
    entry = {"ts": time.time(), "owner": draft.brief.owner,
             "approved_by": approved_by, "goal": draft.brief.goal,
             "learning_question": draft.brief.learning_question}
    with open(path, "a") as f:
        f.write(json.dumps(entry) + "\n")
    return entry

What this shows

The agent writes the draft. The code checks it. A named person approves it. The log says who. The four things an agency can still sell sit in these 40 lines: strategy (the brief), system design (the gate), oversight (the approval) and accountability (the owner field).

Limits

This catches only phrase rules. It does not judge tone or truth. A real setup needs a human reader and your own legal review. This is a sketch.

Tej Pandya, founder of GrowEasy.ai.

A Control Plane for an AI-Run Firm: Workflow, Agent and Human Lanes

Tej Pandya — Sun, 18 Oct 2026 05:04:02 +0000

"Autonomous company" sounds like a model choice. In practice it is a control-plane design. This post sketches one for a small service firm doing lead intake. The firm is illustrative, not a customer story, and I have no results to share.

The idea

Split every task into one of three lanes and enforce the lane in code.

from enum import Enum
from dataclasses import dataclass

class Lane(Enum):
    WORKFLOW = "fixed steps, no model decisions"
    AGENT = "model picks steps, inside limits"
    HUMAN = "person decides"

@dataclass
class Task:
    name: str
    lane: Lane
    tools: list[str]
    needs_approval: bool = False

TASKS = [
    Task("capture_lead",   Lane.WORKFLOW, ["crm.create"]),
    Task("send_reminder",  Lane.WORKFLOW, ["email.send_template"]),
    Task("draft_reply",    Lane.AGENT,    ["crm.read", "email.draft"]),
    Task("quote_price",    Lane.HUMAN,    []),
]

Anthropic's guide says coded workflows give predictability for well-defined tasks, and that agents bring higher cost and compounding errors, so test them in sandboxes with guardrails. Salesforce describes "hybrid reasoning" that combines deterministic logic and adaptive AI. The lanes above are one simple way to do that.

The router

def route(task: Task, payload):
    log("start", task.name, payload)
    if task.lane is Lane.HUMAN or task.needs_approval:
        return queue_for_human(task, payload)
    if task.lane is Lane.WORKFLOW:
        return run_steps(task, payload)
    return run_agent(task, payload, allowed_tools=task.tools)

Three things live here and not in a prompt: which tools a task may touch, which tasks need approval, and what gets logged.

Incident handling

PAUSED = set()

def pause(task_name: str, who: str):
    PAUSED.add(task_name)
    log("paused", task_name, who)

Check PAUSED at the start of route. Someone must own the pause, and the log must say who used it.

Red lines to code first

Money, contracts and customer promises always go to a person.
Every agent action has a log entry with inputs and outputs.
Every task has a named owner and an off switch.

What this is not

It is not proof that a company can run itself. Microsoft's 2025 Work Trend Index describes humans setting direction and "checking in as needed". The control plane is how that check-in becomes real.

Tej Pandya, founder of GrowEasy.ai.

Make Your Store Callable by AI Assistants: A Feed and Tool Contract Sketch

Tej Pandya — Sat, 17 Oct 2026 05:09:54 +0000

If an assistant is going to buy from you, two things must be machine-readable: what you sell (the feed) and what the assistant may do (the tool). This post sketches both. It is a design sketch, not a copy of any platform spec.

The seller here is an illustrative shoe retailer, not a customer story.

Part 1: the feed

OpenAI's product feed docs describe structured catalog data that lets ChatGPT show products with accurate pricing, availability and seller context. Google's UCP guide says it builds on existing Merchant Center shopping feeds. So start with clean rows:

{
  "id": "shoe-123-42",
  "title": "Trail runner, size 42",
  "price": {"amount": "89.00", "currency": "EUR"},
  "availability": "in_stock",
  "seller": {"name": "Example Shoes", "return_days": 30},
  "url": "https://example.com/p/shoe-123"
}

Check your platform's own schema for the real field names. Treat the sketch above as a shape, not a spec.

Part 2: the tool contract

Apps in ChatGPT are built on the open Model Context Protocol, so a tool is a name, a typed input and a typed result.

from pydantic import BaseModel

class BuyShoe(BaseModel):
    product_id: str
    quantity: int
    idempotency_key: str     # same key, same order, no double charge
    buyer_approved: bool     # a person said yes

def buy_shoe(req: BuyShoe):
    if not req.buyer_approved:
        return {"status": "needs_approval"}
    return create_order_once(req)

Two choices matter. The idempotency key stops a retry from ordering twice. The approval flag keeps a human in the loop, which matters because most purchases will still need approval.

Part 3: who stays responsible

Google states that under UCP the merchant stays the Merchant of Record. Your order, refund and customer records stay yours, so your tool should write them the same way as a website order.

What to verify before building

Is your region, plan and industry supported? Announcements name specific surfaces and markets.
What are the fees and review steps? I did not verify them.
Does the platform's ranking favor you? Unknown.

Next step

Ship the feed first. It helps in any channel. Then add one tool, with a key and an approval step, and watch the logs.

Tej Pandya, founder of GrowEasy.ai.

Turn a Job Role Into an Agent Task Spec: Scope, Limits and Escalation in Code

Tej Pandya — Sat, 17 Oct 2026 05:04:47 +0000

When a team says "we want an AI employee", the first job is not picking a model. It is cutting a role into tasks you can specify, limit and check. Here is one way to write that down as code.

This is an illustrative role (sales operations analyst), not a customer story. I have no performance numbers to share.

Step 1: List tasks, not the role

from dataclasses import dataclass, field
from typing import Literal

@dataclass
class TaskSpec:
    name: str
    inputs: list[str]
    allowed_tools: list[str]
    output: str
    owner: str                      # a named human
    escalate_when: list[str] = field(default_factory=list)
    mode: Literal["workflow", "agent"] = "workflow"

TASKS = [
    TaskSpec("clean_lead_list", ["crm.leads"], ["crm.read", "crm.update_field"],
             "list of fixes with reasons", owner="ops_lead",
             escalate_when=["merge two records"]),
    TaskSpec("draft_followup", ["lead", "last_call_notes"], ["crm.read", "email.draft"],
             "draft only, never sent", owner="sales_rep",
             escalate_when=["price mentioned", "refund mentioned"]),
]

Notice mode. Anthropic's guide separates workflows (fixed code paths) from agents (the model picks the steps) and says agents bring higher cost and compounding errors, so test them in a sandbox with guardrails. Start every task as a workflow. Move one to agent only when the steps truly cannot be fixed.

Step 2: Enforce the limits outside the model

def run(task: TaskSpec, call_tool, request):
    for step in plan(task, request):
        if step.tool not in task.allowed_tools:
            return escalate(task, f"tool not allowed: {step.tool}")
        if any(w in step.text.lower() for w in task.escalate_when):
            return escalate(task, f"rule hit: {step.text[:60]}")
        result = call_tool(step)
        audit_log(task.name, step, result)
    return finish(task)

The allowed list and the stop words live in your code, not in a prompt. A prompt can be argued with. A check in code cannot.

Step 3: Make a person own each task

owner is a required field. If a task has no owner, it does not ship. The owner reviews a weekly sample from the audit log and can switch the task off.

Step 4: Keep the claims small

Draft, do not send, until the owner trusts a task.
Log every tool call with inputs and outputs.
Write the stop rules from real incidents, not guesses.

What I would not claim

An agent here is a bundle of tasks with limits. It is not an employee in any legal sense, and this spec does not replace a role. Microsoft's 2025 Work Trend Index describes agents as "digital colleagues" taking tasks at human direction, and calls the person who manages them an "agent boss". That matches the owner field above.

The next step is a review loop: sample the log, tighten the rules, then widen the task.

Tej Pandya, founder of GrowEasy.ai.

Design an Agent-Callable Action: Schema, Idempotency, Scoped Auth and Receipts

Tej Pandya — Fri, 16 Oct 2026 05:19:39 +0000

If you want an AI agent to act on your service without driving your web UI, the useful unit is one well-defined action. This is a design note, not a claim about any vendor's product.

Why not just let the agent use the page

A screen has no contract. A change in a button label or a modal can break the flow, and every page the agent reads can contain text written to mislead it. Anthropic's write-up on browser use says prompt injection is a real, unsolved risk for agents that read web pages. A narrow action reduces what an agent reads and what it can do.

Keep a browser path as a fallback for things you cannot expose. Do not pretend it does not exist.

1. Describe the action as a schema

{
  "action": "book_appointment",
  "inputs": {
    "service_id": "string, from /services",
    "start_time": "ISO 8601, must be an open slot",
    "customer_ref": "string, issued by your auth"
  },
  "result": {
    "booking_id": "string",
    "status": "confirmed | rejected",
    "reason": "string, only if rejected"
  }
}

Fixed fields beat free text. The caller cannot invent a service that does not exist, and you can reject bad input with a clear error.

2. Make retries safe with an idempotency key

Agents retry. Networks fail. Ask for a key on every action that changes something.

POST /book
Idempotency-Key: 7f3c-example

If the same key arrives twice, return the first result and do not book twice.

3. Scope the permission

Give the agent a credential that can do only this action, for this customer, for a limited time. Do not hand over a full account login. If the action can spend money or send a message, require the customer to confirm it.

4. Return a receipt

Every successful action returns an ID and a plain summary the agent can show the customer: what was done, when, and how to undo it.

5. Log the call

Record who asked, what was asked, and what you returned. When an agent and a customer disagree, this is the record.

Where it is heading

Google's Universal Commerce Protocol guide describes an open standard for agentic actions, starting with direct buying in AI Mode in Search and Gemini. Whether you use that or your own endpoint, the same four pieces apply.

Limits

Many services have no API today, and for them a browser is the only route. An API with a broad key is also not safe. The design above is a starting point I think is worth testing.

I'm Tej Pandya, founder of GrowEasy.ai.

Build a Per-Customer Product List Without Letting the Model Invent Products

Tej Pandya — Fri, 16 Oct 2026 05:05:22 +0000

If an assistant builds a product list for one customer at the moment they ask, the hard part is not the language model. The hard part is making sure every item on the list is real, in stock and priced right. This is a design sketch for that, written as a forecast of one pattern, not as a description of a shipped product.

Start with the rule: the model never creates inventory

Public examples show the right split. Zomato's MCP server exposes restaurant discovery, menu browsing with prices, cart creation and ordering. The AI tool calls those functions and reads real menus. It does not make up dishes.

Use the same rule in your own system. The assistant can choose, filter, rank and explain. It cannot add an item that is not in your product records.

The pipeline

Intent in. Customer message arrives in chat, for example from a click-to-WhatsApp ad.
Classify. A small classification step turns free text into a typed decision: category, budget band, urgency, confidence. TypeSafe describes its Jev model this way: unstructured input in, typed probabilistic decisions out, and no free text generation. A classifier is a good fit because the next code step needs a value from a fixed list, not a paragraph.
Branch on confidence. Below a threshold, ask one clarifying question or hand over to a person.
Retrieve. Query your own product store with the typed fields. Pull from approved documents for product facts.
Check live state. Re-read price and stock right before showing the list.
Rank and explain. The language model writes a one-line reason per item, using only fields it was given.
Review. The customer confirms. Nothing is bought without that step.

A schema that keeps the model honest

{
  "intent": {"category": "string (enum)", "budget_max": "number", "confidence": "0..1"},
  "items": [
    {"sku": "must exist in product store",
     "price": "from live read",
     "in_stock": "from live read",
     "reason": "max 20 words, uses only retrieved fields",
     "sponsored": "boolean"}
  ]
}

Reject the whole response if any sku is not found in the store. Do not try to repair it.

Guardrails worth writing as tests

Unknown sku: response is dropped and logged.
Stale price: if the live read differs from the retrieved value, show the live value.
Sponsored items: always flagged, never hidden inside "recommended".
Personal data: only use data the customer agreed to share. The FTC's January 2025 surveillance pricing study press release is a good reason to keep price rules the same for everyone unless you can explain a difference.
Reorder and compare: keep a stable category view. People still want it.

Keep the feed clean

Everything above depends on clean records: title, plain description, price, availability. Google Search Central tells merchants to share product data through structured data and Merchant Center feeds, and says the Content API suits quick stock updates. If your data is wrong, a per-customer list only gets the wrong answer faster.

What I am not claiming

I am not claiming any vendor ships this whole flow today. Amazon's Interests and Rufus, and Spotify's Prompted Playlist beta, show pieces: prompt-driven lists, memory, refresh. The full pipeline above is a design I think is worth testing.

I'm Tej Pandya, founder of GrowEasy.ai.

Define a Lead Handoff Record Before You Report Lead Counts

Tej Pandya — Tue, 13 Oct 2026 05:06:02 +0000

By Tej Pandya, founder of GrowEasy.ai

A lead count is easy to report. A handoff is harder to define. This post sketches a small record that makes the handoff checkable. It is an illustrative design, not a deployed GrowEasy.ai feature.

Name the fields the next person needs

A record the sales team can act on might hold:

lead_id
source_campaign
stated_intent
budget_signal
timing
question_asked
contact_consent
next_owner
handoff_status        (offered, accepted, rejected, expired)
rejection_reason
downstream_stage

This is a starting point. Each team should agree its own fields with the vendor sending the leads.

Count status changes, not rows

A raw lead is a row. A handoff has states. Track offered, accepted and rejected, and keep the reason when someone rejects it. A rejection reason is data a form fill never gives you.

Feed stages back to the ad platform

Google Ads documents qualified lead and converted lead goals so stages tracked offline in a CRM can feed back into optimization. It also provides a lead funnel report from interactions to converted leads. See https://support.google.com/google-ads/answer/11459091?hl=en

Enhanced conversions for leads adds user-provided data, such as an email, to imported offline results to improve accuracy and bidding. Google notes the upload route is moving to the Data Manager API, so check the current method before you build. See https://support.google.com/google-ads/answer/15713840?hl=en

For Meta, a third-party Zapier guide advises picking a middle funnel stage that happens often enough to learn from and inside the platform's attribution window, which that guide gives as 28 days. This is not Meta documentation, so check Meta's own docs. See https://zapier.com/blog/meta-guide-to-better-lead-quality/

Choose the stage on purpose

Do not send only the sale if your sales cycle is long. A stage like "discovery call completed" may arrive in time and often enough to matter. Pick it with your sales team, not with the ad vendor alone.

Check consent and data quality first

Do not send contact data back to an ad platform unless your consent terms allow it. Dirty CRM stages send a dirty signal, so fix stage definitions before you automate.

Test the record

Try a lead with no consent, a rejected handoff with a reason, a handoff accepted after the window closes, and a duplicate lead. Check the record and the owner in each case.

Sources:

https://support.google.com/google-ads/answer/11459091?hl=en

https://support.google.com/google-ads/answer/15713840?hl=en

https://zapier.com/blog/meta-guide-to-better-lead-quality/

Model a Call-to-CRM Handoff as Linked Events, Not One Summary

Tej Pandya — Mon, 12 Oct 2026 05:05:49 +0000

By Tej Pandya, founder of GrowEasy.ai

A call-first sales workflow crosses several boundaries: the call provider, a transcript, messaging history and the accepted customer record. A single "latest summary" field hides those boundaries.

The design below is illustrative, not a deployed GrowEasy.ai feature. Its goal is a handoff that survives delayed sources and uncertain identity.

Keep the source event and the customer identity separate

Store the provider's event identifier alongside an internal customer identifier and the basis for linking them. Do not make a display name the customer key.

Twilio Flex documents a concrete reason for this caution: inbound WhatsApp identity can be a Business-Scoped User ID rather than a phone number. Flex also does not display the customer's WhatsApp profile name. Check the identifiers the actual integration returns before joining its messages to a CRM contact.

A possible event shape is:

provider_event_id
channel_identity
customer_id
identity_link_basis
source_reference
occurred_at
received_at
proposed_change
accepted_change_reference
review_owner

This is a starting point, not a universal schema. An unresolved match should remain unresolved rather than create a confident but wrong history.

Separate a completed call from a completed record update

A call ending does not prove that its transcript is ready or that the CRM accepted the next action. Track those outcomes separately.

DILR's integration analysis describes delayed transcript events, field validation failures and write-back retries. Treat these as cases to test with your provider, not a guarantee that every connector behaves the same way.

A useful state model can distinguish source received, identity unresolved, proposal prepared, write accepted and review needed. Keep failure ownership visible instead of inferring success from the agent's reply.

Recover from current state before accepting a proposed appointment

Suppose a rep changes a visit time while the transcript is being processed. The older conversation should not overwrite the newer accepted appointment without a conflict check.

Validate the target record, allowed change and current revision. If they disagree with the proposal, keep the current record and route the conflict. Source history should explain a proposed change; it should not automatically outrank a later accepted decision.

Treat recording references as access-controlled inputs

Twilio's Recording resource supports fetching and deleting recordings and downloading completed media stored at Twilio. Its recording documentation warns that applicable consent laws must be followed.

Store the reference and the access decision deliberately. Do not expose an entire recording merely because a rep needs one accepted next step. Recording consent is not a blanket permission for unrelated future use.

Define how a deleted source affects cached summaries and source links. An export that contains broken media references is not a successful portability test.

Test the handoff instead of testing only the conversation

Try a delayed transcript, an ambiguous channel identity, a repeated event, a failed CRM write and a changed appointment. Verify the accepted record and responsible owner for each case.

A reliable integration can make the next call easier without replacing the CRM. The architectural goal is continuity with visible uncertainty, not a larger field of prose.

Sources:

https://www.twilio.com/docs/flex/developer/conversations/receive-inbound-messages-from-sms-and-whatsapp

https://www.twilio.com/docs/voice/api/recording

https://www.twilio.com/docs/voice/twiml/record

https://www.dilr.ai/blog/voice-ai-crm-telephony-integration-architecture-enterprise

Build an Agent-Friendly Customer Record Before Replacing the CRM Screen

Tej Pandya — Sun, 11 Oct 2026 05:08:27 +0000

By Tej Pandya, founder of GrowEasy.ai

A conversational sales interface is easy to demonstrate. A customer record that survives conflicting updates is harder to build.

If an agent can read a lead, propose a visit and write a follow-up, the application needs more than a text field for the latest summary. It needs identity, access rules and a way to distinguish proposed changes from accepted state.

The design below is illustrative. It is not a deployed GrowEasy.ai feature or a customer result.

Give every customer a stable identifier

Do not use a name as the record key. Two buyers can share a name; one buyer can use several contact routes. Keep external identifiers and source references alongside the internal customer identifier.

A possible record sketch is:

customer_id
source_record_refs
record_revision
record_owner
permitted_contact_state
current_appointment
pending_changes

This is a starting point, not a universal schema. The fields should follow the business process and its privacy requirements. A model's confidence should not decide whether two customers are merged.

Validate proposed writes against current state

Let the model propose a structured change. Validate the target record, allowed fields, permissions and revision before accepting it.

If a rep changes the appointment while the agent is preparing a reminder, the older proposal should not silently overwrite the newer time. Return a conflict and recover using the current record.

The accepted record change and a completed external action are separate outcomes. Saving a callback request is not proof that someone made the call.

Scope access to the actual person and action

Salesforce's custom-action documentation distinguishes employee-facing agents from service agents. It calls for record and field access checks, and verified customer identity scoped to private service-agent actions.

That is a useful design warning: an agent's execution identity may have broader access than the customer it serves. The application must enforce the customer's boundary. Do not accept an arbitrary record ID from a prompt as proof of ownership.

These requirements belong to Salesforce's documented product context. They are not a claim about every platform's implementation.

Check what the connector really exposes

HubSpot's remote MCP guide describes supported reads and writes with existing user permissions. Availability varies by subscription, permissions and configuration. Sensitive Data settings block activities and conversations through MCP even though standard CRM APIs are a different route.

Treat the connector's documented coverage as an integration boundary. A natural-language interface cannot make an unavailable object available.

Design audit coverage instead of assuming it

Microsoft's Dataverse guidance says auditing must be configured at environment, table and column levels. Logs can be delayed and follow retention settings. Record auditing does not cover retrieve and export operations without additional activity logging.

Before launch, test which changes are recorded, whose identity appears and whether the history can explain a disputed update. Keep only the data the business needs, with an explicit retention policy.

Keep a correction screen for unresolved changes

A useful human view shows the current value, proposed value, relevant source and responsible owner. Test two similar customers, stale updates, revoked access and missing source history.

The aim is not to prove that screens are obsolete. It is to make routine work easier without weakening the record people depend on.

Sources:
https://developer.salesforce.com/docs/platform/isvforce/guide/secure-agentforce-actions.html
https://developers.hubspot.com/docs/apps/developer-platform/build-apps/integrate-with-the-remote-hubspot-mcp-server
https://learn.microsoft.com/en-us/power-platform/admin/manage-dataverse-auditing