DEV Community: Tej Pandya

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

Model a Sales Reminder as a State Machine, Not a Prompt

Tej Pandya — Sat, 10 Oct 2026 12:39:13 +0000

By Tej Pandya, founder of GrowEasy.ai

A reminder agent needs somewhere to store what it owes. If the only record is the conversation, developers cannot reliably tell whether an action was planned, attempted or completed.

This example is a design sketch for an appointment-led sales workflow. It is not a deployed customer result or a GrowEasy.ai feature claim.

Keep scheduling state separate from message text

Store an appointment revision, confirmed time, consent state, contact route and reminder status. A change to the appointment should invalidate pending work tied to an older revision.

The model can extract a proposed time from a message. Application logic validates it before updating the record. Unknown consent stays unknown; it is not filled from the model's confidence.

An illustrative transition sketch:

requested -> confirmed -> reminder_eligible -> attempted
attempted -> delivered | retryable_error | permanent_error
retryable_error -> reconciled | retry_pending | needs_human
needs_human -> assigned -> accepted -> completed

These states are not a universal standard. Choose them around the real work and the provider's actual receipts. Do not interpret "delivered" as "attended".

Reconcile ambiguous tool results before retrying

When a request times out, it may already have succeeded. Look up the provider result or reuse a supported idempotency key before repeating the side effect.

A key might identify the appointment revision and reminder type. It must not suppress a genuinely new reminder after the buyer changes the appointment.

Temporal's documentation recommends idempotent Activities because retry behavior can repeat execution. Durable state and safe side effects solve different problems; you need both.

Put eligibility checks immediately before the effect

Before a reminder sends, re-check current appointment state, consent, permitted time and destination. A job that was eligible when queued may no longer be eligible when it runs.

Treat refusal and revoked consent as stop conditions. Distinguish temporary transport errors from permanent failures. A retry budget is an application decision, not something the model should improvise indefinitely.

Give the human fallback a real lifecycle

An exception record needs a question, current evidence, requested time and owner. Assignment is not acceptance. An overdue unaccepted task should remain visible to the team.

Do not tell the buyer that a callback is confirmed if the application only emitted a notification. Gate that sentence on the state that proves a responsible person and valid time exist.

Test changed state and repeated execution

Test a cancellation after queueing, duplicate webhook delivery, two workers claiming the same job, a provider success followed by a lost response, an unavailable owner and an explicit request for a person.

Check the resulting records and external actions, not only the agent's wording. Compare the design with a simpler deterministic baseline. Anthropic's workflow guidance is useful here: add model-driven flexibility where it is needed rather than turning every predictable step into an autonomous decision.

A clean state machine cannot fix bad rules. It can make those rules, and their failures, visible enough to test.

Sources:
https://www.anthropic.com/engineering/building-effective-agents
https://docs.temporal.io/activity-definition
https://temporal.io/blog/idempotency-and-durable-execution

Build an AI Lead Handoff That a Sales Rep Can Actually Use

Tej Pandya — Fri, 09 Oct 2026 05:10:51 +0000

The most important output of a sales qualification agent may be the handoff record, not the last message it sends.

My prediction is that AI will take more of intake and follow-up while humans handle complex selling. For developers, that means the boundary between the two jobs needs a data contract. A long generated summary is not enough.

The example below is illustrative. It is not a claim about a deployed customer or a GrowEasy.ai feature.

Keep confirmed facts separate from model guesses

Imagine an enquiry for a property visit. The buyer gives an area and a rough budget, but has not decided when to buy. Store the timing as unknown. Do not turn "just looking" into "purchase within thirty days" because your qualification schema expects a value.

{
  "buyer_answers": {
    "area": {"value": "requested area", "source_message": "message-12"},
    "budget": {"value": "buyer stated range", "source_message": "message-15"},
    "purchase_timing": {"value": null, "status": "not_confirmed"}
  },
  "open_questions": ["Buyer asks about financing terms"],
  "handoff_reason": "Needs an authorised human answer",
  "owner": null,
  "callback_window": null,
  "status": "awaiting_assignment"
}

The fields are an example contract, not a required standard. What matters is that evidence and uncertainty remain visible. A lead score can help sort work, but it should not silently replace the actual answers.

Make rep acceptance a state, not a hopeful sentence

Use separate states for awaiting assignment, assigned, accepted, contacted and closed. Do not mark a handoff complete just because a message entered a queue.

If nobody accepts, trigger a team-visible fallback. If the buyer's requested time passes, record that the callback was missed. Do not let a summary or a notification stand in for ownership.

The buyer-facing agent should only say that a callback is confirmed when a real owner and a valid time exist. That rule belongs in application logic, not only in a prompt.

Route commitments away from the qualification tool

An intake agent may collect preferences or explain approved information. It should not invent an exception to contract terms, approve credit, promise legal clearance or negotiate a concession.

Use restricted tools and approved knowledge. Escalate conflicting answers, unsupported questions and explicit requests for a person. The model should be able to say what it does not know.

Salesforce's Agentforce sales page separates qualification, routing, follow-up and sales insights. That supports a modular design. It does not prove that unrestricted autonomy improves conversion.

Test duplicate messages and failed handoffs before conversion

Start with failure cases:

The buyer changes the budget after the initial summary.
The buyer requests a human before answering every question.
Two reps try to accept the same enquiry.
A reminder arrives after the appointment has been cancelled.
A model claims the buyer agreed to a callback without a supporting message.

These tests should inspect stored state and the buyer-facing response. Include a repeat-message test so a retry does not create two callback requests.

Measure downstream quality, not chatbot activity

Response time and completed fields are useful, but incomplete. Check rep acceptance, callback completion, meeting attendance, qualified opportunity rate and eventual close rate. Add false rejection, incorrect promises and complaints.

AI-assistance research in customer support has found productivity gains, with differences by worker experience. That is not a promised sales uplift. Compare this handoff with your current process on similar leads before making a performance claim.

A qualification agent has done its job when the next person can act correctly. A fluent conversation that leaves nobody responsible is still a failed workflow.

Tej Pandya, founder of GrowEasy.ai

Sources:

AI disclosure: Written with autonomous AI assistance and checked against the linked sources.

Build an Industry-Onboarding Preview, Not a Prompt That Rewrites Your CRM

Tej Pandya — Thu, 08 Oct 2026 09:27:31 +0000

Separate connector access, proposed configuration and approved changes before adapting one CRM to different industries.

By Tej Pandya, founder of GrowEasy.ai

I expect more vertical software to become a setup choice on a shared core. For builders, the important question is what happens between "tell us your industry" and "save these changes".

A model can suggest qualification questions. That does not make it safe to rewrite fields, permissions or live records. Treat the suggestion as a proposed configuration, with a review step before it touches the system of record.

Put a typed configuration between the model and the CRM

For an illustrative training-company setup, the proposal might contain a course field, preferred start date, an intake question and a human-handoff rule. An interior-design setup might propose project location and room type instead.

Keep each proposal explicit: field name, type, purpose, allowed values, required status and which workflow uses it. A free-text prompt is not a migration plan. Check the proposal against the CRM's supported objects and the customer's existing fields.

MCP access does not grant permission to change the schema

HubSpot's remote MCP server is generally available. Its April 2026 changelog lists read access and create/update access separately. Supported writes include contacts, companies, deals, tickets, line items and products; some other objects remain read-only.

The connection uses OAuth 2.1 with PKCE and respects existing HubSpot user permissions. When sensitive data is enabled, Activity objects are blocked through this MCP server. None of that release establishes automatic industry-specific schema rewriting.

Build against the tools and permissions actually available to the connected account. If a required operation is unavailable, show that limit instead of generating a plausible tool call.

Preview the difference and test it with fictional records

A useful preview compares the current configuration with the proposal. Show added fields, renamed fields, changed validation and affected reports. Do not hide a destructive change among harmless labels.

Run fictional leads through both versions. Check that qualification, handoff and reporting still mean what the owner expects. Keep the old configuration available, and define how to recover if a change is wrong. These are design recommendations, not a claim that we have shipped this system.

Keep specialist logic outside the generic setup promise

SAP's generative-UI article points toward task-specific interfaces, but also stresses live system-of-record data, familiar structures and complex business logic. A generated form does not replace those foundations.

The goal is a shared core that can express different workflows, not a model pretending every industry's rules are interchangeable. Keep unsupported industries and untested integrations visibly untested.

Sources: https://developers.hubspot.com/changelog/remote-hubspot-mcp-server-is-now-generally-available ; https://news.sap.com/2026/03/why-is-generative-ui-the-new-frontier-for-business-software/