DEV Community: Tej Pandya

Agents Need Better APIs, Not Just Fewer Screens

Tej Pandya — Mon, 28 Sep 2026 18:47:04 +0000

A human interface is not the whole product. If software's main job is to make a person repeat clicks, an agent may eventually take those clicks away. But the database, permission checks, payment network and message delivery still have to work.

Here is how I would redesign one workflow for that future: a customer asks to move an appointment.

Today: a screen-led workflow

A staff member opens a calendar, finds the customer, checks the original appointment, looks up the available slots, changes the booking, sends a message and writes a note. The screen holds all the steps together because a person is doing the work.

An agent-facing workflow cannot just expose a button that says "edit booking." It needs specific operations and rules.

Give the agent a narrow set of tools

I would separate the capabilities:

get_booking(booking_id): return the current time, status and owner.
list_available_slots(service_id, date_range): return slots the business can actually honor.
propose_change(booking_id, new_slot): check policy and hold the slot briefly, without yet telling the customer it is booked.
commit_change(proposal_id): make one durable change, with an idempotency key so a retry does not create two bookings.
send_confirmation(booking_id): send the new details only after the commit succeeds.

The model can interpret a customer's request. The service should enforce the booking rules. If the slot disappears or the booking belongs to someone else, the API must reject the change clearly rather than letting the model invent a success.

This is the boundary between reasoning and execution. Anthropic's agent design guide distinguishes fixed workflows from more flexible agents. Its Model Context Protocol offers a way for systems to expose tools and context. OpenAI's function-calling guide likewise describes models requesting tool calls while the application executes them. These documents show the design route, not proof that every business workflow is ready to automate.

What cannot be left to the model

A useful agent tool needs a contract:

Identity: who is requesting the change, and can they touch this booking?
Consent: can the business contact the customer on this channel?
State: what changed since the agent last read the record?
Undo: when can a change be reversed, and what does that cost?
Audit: which tool call changed what, and who approved it?
Fallback: what happens when a rule, payment or availability check fails?

The old app may still need a screen for a person to review an exception. "No UI" is not the goal. Fewer unnecessary human steps is.

The infrastructure test

Before building a chat front end, ask a harder question: can a machine call the core service safely, and can the service say no? If not, the new interface only hides a brittle process behind fluent words.

My prediction is that more value moves to these callable capabilities and the systems that carry them. Telecom still delivers the call. A payment rail still settles the charge. A database still records the change. An agent changes who operates the workflow, not whether those systems exist.

At GrowEasy.ai, where we build AI-assisted sales workflows, this is the design question I keep returning to: when an agent hands a lead to a human, is that a chat message, or a durable, permissioned state change the next person can trust?

Tej Pandya, founder of GrowEasy.ai

Build for Tasks, Not Only Prompts

Tej Pandya — Sun, 27 Sep 2026 18:41:33 +0000

The web was designed around a person looking at a page. A personal agent changes the caller: software may read the data, compare options and ask a person to approve the last step.
That does not make every website obsolete. It makes the hand-off between information and action a product design problem.
OpenAI's ChatGPT search provides answers with links to web sources. ChatGPT agent can navigate websites and do multi-step work, while asking permission before consequential actions. Those are different layers. One helps answer "what is true?" The other attempts "what should happen next?"
For developers, I think the second layer changes what a good integration looks like.

Start with a real task

Take a small retailer that wants an assistant to help a customer choose a desk chair. The customer says: "I need one under my budget, delivered by Friday, with a return policy I can live with."
A brittle integration hands the agent a catalogue page and hopes it can read the cards. A useful one makes the relevant facts explicit: exact variant, price, stock, delivery area and date, return terms, and when those facts were checked. The agent can then compare candidates and cite the records that support the choice.
The request is not "generate a chair recommendation." It is a workflow with inputs, live checks and a decision gate.

Make failure legible

Suppose stock changes between the shortlist and checkout. The integration should not silently substitute another chair. It should return an out-of-stock state, preserve the customer's constraints and ask for a new choice. The same applies when the delivery date moves, an API returns partial data, or the exact variant is missing.
Useful interfaces distinguish "not found" from "not checked" and "unavailable." They also expose a timestamp. An agent cannot compensate for stale data by writing a more confident sentence.

Separate reading from committing

Discovery can be broad. A purchase, booking or message is narrower. Give an agent read access to compare options without giving it an unlimited right to spend money or speak for a user. At the committing step, show the final item, amount, destination and cancellation terms to the person who owns the decision.
This separation also helps debugging. If the task fails, a trace should tell you whether the source data was wrong, the selection was wrong, or the final action failed. "The agent said it worked" is not an audit log.

Package repeat work

A prompt is a poor place to store a recurring workflow. Write down the task's inputs, allowed tools, check cadence, success condition, exceptions and human review points. Keep mutable state outside the prompt. Then a different model or interface can run the same job without reconstructing the rules from old chat messages.
I expect the prompt box to remain. It will be the place where a person changes a goal or asks for an explanation. But the value of an agent will come from whether it can complete the right task, check the result and stop at the right moment.
I am not claiming search traffic or websites have already vanished. Search remains useful for navigation and source checks. The builder question is simpler: if a customer's assistant arrives tomorrow, can it tell what your service offers, whether the offer is current, and what action requires the customer's approval?
Tej Pandya is the founder of GrowEasy.ai.
Further reading: OpenAI on ChatGPT search, OpenAI on ChatGPT agent, and the AI Agent Skills team's related essay.

Build for Inbound: Why AI Receptionists and Chat Agents Beat AI Cold Callers

Tej Pandya — Fri, 25 Sep 2026 07:19:52 +0000

If you're building an AI voice or messaging product right now, the easy demo is outbound: an AI that calls or emails a thousand leads. I think that's the wrong thing to build. Here's the case for building inbound instead.

Outbound AI runs into people and rules

Gartner found 64% of customers would prefer companies didn't use AI for customer service, and 53% would consider switching over it.
The US FCC ruled in February 2024 that AI-generated voices count as "artificial" under the TCPA. AI cold calls get treated like robocalls.
Only 19% of Americans generally answer unknown numbers anyway.

The one outbound use that works is calls people expect: reminders, delivery updates, payment due dates. The value is the information, not the pitch.

Inbound flips the problem

When someone calls a clinic or a salon, they want an answer: price, slot, address. They'll talk to an AI if it's fast and correct. And small businesses miss a lot of these calls. One older study put it at 62% unanswered.

So the build is different:

Low latency matters more than a clever voice. The caller wants the answer now.
Ground answers in the business's real data: prices, hours, availability. A wrong slot is worse than no answer.
Know when to hand off. Hot leads and upset callers should reach a person fast.
Log everything to the CRM so the follow-up happens.

Email agents change what "delivered" means

Gmail summary cards and Apple Mail's summaries mean an assistant often reads mail first. If you build email tooling, design for a machine reader: clear subject, the ask in the first line, no fluff. Also know the rules: Gmail requires bulk senders to keep spam complaints under 0.3%.

Chat is the best interface for AI agents

WhatsApp has 3B+ monthly users. Chat is async and started by the customer, so an AI reply doesn't feel like an interruption. Some things to get right:

Tell people when they are chatting with an AI. It builds trust and avoids misleading them. Disclosure rules vary by place and use case.
Keep a person in the loop for pricing exceptions and complaints.
Connect the chat to ads (click-to-WhatsApp) and the website, so every entry point lands in one place.

What we build

At GrowEasy.ai we took this path: TalkEasy, an AI receptionist for inbound calls, plus WhatsApp chat that replies to leads from ads. We don't do AI cold calling.

Question for you

if you're building voice or chat agents, where have you seen people accept AI, and where do they hang up?

Tej Pandya, founder of GrowEasy.ai

Sources: Gartner, FCC, Pew, Google.

What Dropbox Can Teach Us About Sharing AI Tools

Tej Pandya — Thu, 24 Sep 2026 15:16:53 +0000

Dropbox gave you 500 MB of free space for every friend who signed up, and gave your friend the same. It didn't ask people to be generous. It made sharing the smart thing to do for yourself.

A lot of AI tools at work need that same push, because right now most people keep them quiet.

People hide the AI tools they use

Surveys from Microsoft, LinkedIn and Slack all point the same way. Many people use AI at work and don't tell their manager or their teammates. The top reasons are that it feels like cheating, or that sharing it means giving away a head start.

That makes sense if the tool only helps one person. But many AI tools work better when more people use them. An assistant that can work with a teammate's assistant, share notes on a customer, or pass along a follow-up gets more useful with every person who joins. If you keep it to yourself, you get only a small part of what it can do.

Some tricks really do stop working when everyone copies them

It's worth being honest about the other side. Some advantages exist only because few people have them. Early banner ads got clicked. Cold email used to get replies. When everyone automates the same channel, it wears out for everyone, and nobody gets read.

One question to ask

Before you pick up any AI tool, ask: does this get better or worse when the people around me use it too?

If it gets better: share it early. Bring in your team and make it easy for them to join.
If it gets worse: expect your advantage to fade. Use it while it lasts and spend that time building trust with real people.

For developers building AI features, the same question applies to what you ship. If your feature gets better as more of a team uses it, build the invite into the product, the way Dropbox did.

That's the idea behind GrowEasy.ai. CRM, WhatsApp and calling live on one platform, so a whole sales team gets better together instead of one person keeping a private trick.

Tej Pandya, founder of GrowEasy.ai