DEV Community: Aharna Haque

I built a WhatsApp AI agent in under 60 minutes, with low-code agent builder

Aharna Haque — Wed, 14 Oct 2026 04:37:39 +0000

Building a WhatsApp agent is trickier than it looks. You write a pile of code for webhooks and message handling. You wire up an LLM, write the prompts, and manage conversation state so the agent remembers what the user said two messages ago. You set up a Meta Business account, get it verified, apply for WhatsApp Business API access, and wait for message templates to be approved. Then you connect a calendar, an email service, and Slack, each with its own auth flow and its own error cases. After that you host it, monitor it, and fix it every time an API changes.

In this post, I'll show you how I built a production-ready WhatsApp AI agent in under 60 minutes, using a no-code agentic platform, DronaHQ.

The use case

The clinic's staff leave at 6 PM. Patients don't stop messaging. They ask about test pricing at 11 PM, try to book for Sunday morning, and reschedule while standing in a coffee queue.

The clinic had a booking portal, but it meant leaving WhatsApp, opening a browser, creating an account, and filling out a form. Most people won't do that. They message instead, and the message waits until morning.

So the agent needed to handle three things inside WhatsApp:

Pricing questions
Appointment bookings
Reschedules

How I chose an agent builder

Most tools now call themselves agent builders, but they do very different things. Some are chatbots with better prompts. Some are workflow automations with an LLM step in the middle. I used this comparison of top AI agent builders as a reference.

My requirement was narrow. The agent had to act across systems in one conversation: check a calendar, write a booking, send an email, notify staff. Here's how I read the options against that.

Botpress is built around conversation and supports WhatsApp. But tool calls are scoped to a single conversational turn, and multi-system backend orchestration is its weaker side.
Zapier Agents has the widest SaaS coverage. But the agent lives inside a Zap, with no standalone agent endpoint, and task-based pricing adds up at scale.
n8n gives you full control and can be self-hosted. But non-trivial logic usually needs JavaScript, and you run more of the infrastructure yourself.

I went with DronaHQ. WhatsApp is a built-in trigger, the Google Calendar, Gmail, and Slack connectors already exist, and the agent can write to those systems. It also has traces, which helped when the agent did something I didn't expect. The tradeoff is that its template library is still small, so I built it from scratch.

Why I chose agent over automation for workflows in WhatsApp (quick primer)

Most people hear "automated WhatsApp responses" and think: chatbots. Auto-replies. Canned messages.

That's not what I built.

Traditional automation follows predetermined paths. If the user says X, do Y. It breaks the moment someone phrases a request differently. It requires you to map every possible variation. It frustrates users because it can't handle nuance.

Have you experienced this?

You message a business: "Can I move my 3 PM slot to Thursday?"

Bot responds: "I didn't understand that. Please choose from: 1) Book appointment 2) Cancel appointment 3) Speak to agent"

You try again: "Reschedule"

Bot: "Please provide your booking ID."

You don't have it. You wait for a human.

That's automation. It's rigid. It breaks under real-world use.

The distinction:

Traditional automation	Agentic workflow
Keyword matching	Intent understanding
Fixed conversation paths	Dynamic responses
Breaks on variation	Handles natural language
"Press 1 for..."	"Just tell me what you need"
Requires extensive mapping	Learns from context

Automation executes scripts. Agents make decisions.

What my WhatsApp-triggered agent actually does

Trigger: A patient sends a WhatsApp message.

Intent detection: The agent reads the message and decides if it's a service query, a booking, or a reschedule.

Action:

Service query → searches the knowledge base, returns pricing
Booking → checks Google Calendar, reserves the slot, collects the patient's email
Reschedule → updates the calendar, sends a new confirmation

Notification layer: Booking details go to staff via Slack, email, and WhatsApp.

Staff only get involved when the agent escalates.

Real-world use cases for WhatsApp AI agents (clinics, restaurants, salons, more)

The clinic is a proxy. The pattern applies anywhere customers initiate service requests via messaging:

Salons booking appointments
Repair services quoting jobs
Tutoring centers scheduling demos
Legal consultations confirming calls
Real estate viewings
Restaurants handling reservations
Service contractors scheduling estimates

The common thread: high-frequency, low-complexity interactions that don't justify pulling someone out of their messaging app.

These aren't edge cases. This is most customer service.

How I built it

I needed three pieces: a WhatsApp trigger, an AI layer that understands intent and picks tools, and integrations for the calendar, email, Slack, and a knowledge base. I recorded a video on it as well in a workshop I hosted.

My earlier guide, how to build AI agents in 5 simple steps using DronaHQ, covers the basics of models, instructions, and testing. If you'd rather watch than read, here's the full build walkthrough.

Step 1: Set up the WhatsApp trigger and AI instructions

I opened DronaHQ's agentic platform and created a new agent workflow. Then I added the instruction (you can copy it from here).

Next, I added WhatsApp as the trigger and connected my business WhatsApp number. Every message that comes in now fires the agent.

Time: 5 minutes.

Step 2: Build the knowledge base

I created a simple knowledge base with:

Vaccine pricing (BCG: ₹600, Covishield: ₹1000)
Doctor consultation fees (Dr. Sharma: ₹500)
Clinic timings and availability

I uploaded it as a structured document. The agent can now search it on demand.

Time: 10 minutes.

Step 3: Configure intent detection (pricing, booking, reschedule)

This is where the agentic layer does the heavy lifting.

I didn't write rules. I just told the agent what kinds of queries to expect:

Service/pricing queries
Appointment booking requests
Rescheduling requests

The AI model handles natural language understanding. Whether someone says "how much is a BCG vaccine" or "BCG vaccine cost?", it knows both are pricing queries.

Time: 5 minutes.

Step 4: Connect Google Calendar for automated bookings

Next, I added the Google Calendar integration and configured it to:

Check the doctor's availability
Book slots when requested
Update existing appointments for reschedules

I used DronaHQ's pre-built connector. I had no API keys to manage. Just OAuth and done.

Time: 10 minutes.

Step 5: Add email and WhatsApp confirmations

I connected the Gmail tool. When a booking is confirmed, the agent:

Asks for the patient's email
Sends a formatted confirmation with appointment details

Again, a pre-built connector. Point and click.

Time: 5 minutes.

Step 6: Configure staff notifications (Slack, email, WhatsApp)

I added three notification actions:

Post to a designated Slack channel with booking details
Send an email to the clinic admin
Send a WhatsApp confirmation to the patient

All three fire automatically after a successful booking.

Time: 10 minutes.

Step 7: Design the visual conversation flow

This is visual workflow design. I mapped:

If message → detect intent
Intent = pricing query → search knowledge base → return result
Intent = booking → check calendar → offer slots → collect email → confirm → notify
Intent = reschedule → find existing appointment → check new availability → update → notify

The platform shows this as a flowchart. I dragged, dropped, and connected nodes.

Time: 20 minutes.

Step 8: Test and deploy

I sent test messages from my phone:

"How much is a BCG vaccine?" ✓
"I want to book for tomorrow at 10 AM" ✓
"Can I move my appointment to Thursday?" ✓

All worked, and I deployed it live. This is a complete WhatsApp AI agent, built end-to-end with no code.

Time: 15 minutes.

Cost: No enterprise licenses. No custom development.

What I didn't have to do

I didn't read API documentation. I didn't configure webhooks, write error handling logic, set up a database, or provision a server.

The platform abstracted all of it.

The operational shift

What changes when this becomes your default interface?

Support load compresses. Repetitive queries (pricing, availability, rescheduling) disappear from your queue. Your team handles exceptions, not routine requests.

Response time flattens. Midnight enquiries get answered immediately. No queue. No business hours. The agent is always on.

Lead capture tightens. Every inbound message is logged, categorized, and actioned. Nothing falls through the cracks because someone forgot to check the inbox.

Data quality improves. Structured capture happens at the point of contact. You're not cleaning data later; the agent forces structure upfront.

This isn't incremental. It's a different operating model.

The automation frontier nobody built yet

Here's what most companies are still doing: they automate internal workflows, approvals, data syncs, reporting pipelines.

That's fine. But the higher-leverage play is automating the customer-facing workflow at the entry point.

Because that's where effort compounds. Every avoided friction point multiplies across thousands of interactions. Every instant response prevents a lost lead. Every automatic confirmation reduces no-shows.

The irony is that the tooling finally exists to do this without engineering armies. Visual workflow builders. Pre-built integrations. AI agents that don't need training data to understand "I need to move my appointment to Thursday."

The infrastructure gap has closed. The adoption gap hasn't.

Cost, time, and build-vs-buy for WhatsApp AI agents

Here's what usually stops companies from deploying this kind of system:

Cost. Enterprise automation platforms run $50K+ annually. Custom development costs six figures.

Complexity. Integrating WhatsApp + AI + Calendar + CRM + Email traditionally requires engineering teams and months of work.

Maintenance. Every API change breaks something. Every new use case requires new code.

The shift happening now: platforms that give you agentic capabilities without writing code or buying enterprise licenses.

Visual workflow builders. Pre-built connectors. AI layers that handle natural language out of the box. You're not buying software. You're assembling intelligence.

I could have built this from scratch: string together Twilio, OpenAI, Google Calendar APIs, and Slack webhooks, write the orchestration logic, handle error states, and maintain it all. Budget: $100K+ in development. Months of work. Ongoing maintenance costs.

Instead, I used DronaHQ, which gave me no-code builder workflows, pre-built connectors, and an agentic layer that handles intent without brittle rule trees. Build time: 60 minutes. Cost: a fraction of custom development. Maintenance: handled by the platform. The math is obvious. Unless you're in the automation business, building this yourself is technical debt disguised as differentiation.

What happens next

The businesses that move first on this aren't waiting for perfect AI. They're deploying agents that handle the 80% of interactions that don't need human judgment.

The businesses that wait are optimizing their web portals and wondering why customers keep texting them instead.

This isn't a future trend. It's operational table stakes.

Your customers are already on WhatsApp. The question is whether you'll meet them there with an agent that actually understands them, or keep sending automated responses that make them want to speak to a human.

The technology exists. The interfaces are ready. The customers are waiting.

What's missing is the decision to deploy.

You can also read more on how agentic AI is designing the experiences of a modern traveller.

Explore how AI agents in WhatsApp are reshaping online travel booking.

Frequently asked questions

How do I build a WhatsApp AI agent without coding?

I used DronaHQ's agentic platform. I configured the AI model, set instructions, uploaded a knowledge base, selected pre-built tools like Google Calendar and Gmail, and chose the WhatsApp trigger in the trigger section, which fires whenever a message arrives on WhatsApp. The platform handled the orchestration, and I had a production-ready agent running in under 60 minutes.

Can I build a WhatsApp AI agent in under 60 minutes?

Yes. I built a fully functional one in under 60 minutes on DronaHQ's no-code agentic platform. I configured the WhatsApp trigger, set the AI instructions, connected the knowledge base, and selected the tools, with no backend development required.

What's the difference between a WhatsApp chatbot and a WhatsApp AI agent?

A WhatsApp chatbot follows fixed, rule-based paths using keyword matching. The agent I built in DronaHQ understands intent through natural language processing, keeps track of the conversation, and triggers the right tools. It makes decisions instead of following rigid scripts.

What tools do I need to build a WhatsApp AI agent in DronaHQ?

I needed a WhatsApp Business account, a knowledge base document, and a few pre-built tools (Google Calendar, Gmail, Slack) selected inside the platform. The tool selection and configuration took me under 60 minutes end to end.

Can I use this WhatsApp AI agent for bookings, pricing, and reschedules?

Yes. The agent I built handles bookings, pricing queries, and reschedules on its own by selecting the right tool based on the user's intent. It searches the knowledge base, checks Google Calendar, and processes reschedules, all configured in under 60 minutes.

How to use AI voice agents for debt collection: A practical guide

Aharna Haque — Fri, 09 Oct 2026 10:17:51 +0000

An AI voice agent for debt collection is software that calls borrowers about overdue balances, holds a real conversation using speech recognition and generative AI, and records what happened, instead of playing a fixed message or waiting for a human to dial. This guide covers where voice agents fit in collections, what they need to get right on compliance, how to set one up, and how to tell whether the calls are working.

Why collections is moving to voice AI

Collections is a volume problem with a people problem inside it. A team dials hundreds of accounts, most go to voicemail, and the few that connect are often tense. It's repetitive, hard to staff, and expensive to scale.

That makes it a natural fit for an outbound voice agent. The work is structured, the goal of each call is narrow, and the cost of an inconsistent call is high.

The important part is what the agent is for. It isn't there to replace your collectors. It handles the early-stage, high-volume and after-hours calls, so your human team spends its time on the accounts that need judgment.

The example: An early-stage payment reminder

Here's the scenario used throughout this guide. A borrower is seven days past due on an instalment. Nothing has gone to a formal recovery stage yet. An outbound agent calls and has one job: find out whether the borrower knows about the payment, and get a commitment or a reason.

This is a good first use case because it's low-stakes and structured. The agent doesn't need to settle a dispute or restructure a loan. It needs one of four outcomes: paid, promise to pay, dispute, or escalate to a human.

That's easy to script, easy to test, and easy to measure.

Compliance comes first

In collections, compliance isn't a feature you add later. It decides whether the program can run at all.

A voice agent can be more consistent than a human team here, because it doesn't have a bad day. It calls inside the allowed window, delivers the required disclosure every time, and logs every word. But it only does that if you set it up to.

Things to confirm before a single call goes out:

Calling hours. In the US, the FDCPA restricts calls outside roughly 8 AM to 9 PM in the borrower's local time. In India, RBI's recovery guidelines are tighter, so check the current rules for your lender type.
Required disclosures. Who is calling, on whose behalf, and that the call is about a debt. Put this in the first message, not buried in the middle of the call.
Consent for automated calls. In the US, the FCC treats AI-generated voices as artificial voices under the TCPA, which raises the bar on prior consent. Get legal sign-off on this one.
Call frequency. Set a cap on attempts per account per week and enforce it in the campaign, not in someone's head.
Recording and retention. Know where recordings and transcripts live and who can access them.
Dispute handling. If a borrower says they don't owe the debt, the agent should log it and stop pressing.

This isn't legal advice. Run the script and the call flow past your compliance or legal team before launch.

Before you start: What you need

Two things need to be ready before you configure anything:

A phone number the agent will call from, connected through your platform or a SIP trunk
Agent instructions: the opening line with the disclosure, the goal of the call, and exactly what the agent does when the borrower disputes, gets upset, or asks for a person

Everything else builds on these two.

Step-by-step setup guide

The steps are platform-agnostic. The specifics use DronaHQ's voice agent as the working example.

Step 1: Connect a number and create the agent

Connect telephony through a SIP trunk. A Twilio Elastic SIP Trunk works if you already run call infrastructure on Twilio. Once connected, route the number to your agent under Call Configuration → Outbound Settings, then create the agent from the admin console.

One constraint to plan around: each number is tied to one agent and one live call at a time. If you're working through a large portfolio in a short window, you'll need more than one number, or the campaign simply takes longer.

Step 2: Write the instructions branch by branch

Set the voice, transcriber and LLM models, then write the first message. Use placeholders. A generic opener sounds like a robocall within two seconds, and in collections that costs you the call.

Something like:

"Hi {{borrower_name}}, this is {{company_name}} calling about your {{loan_type}} payment of {{amount_due}}, which was due on {{due_date}}. This call may be recorded. Is this a good time to talk?"

It names the borrower and the exact payment, and it carries the disclosure up front.

For the instructions, don't write "handle the borrower's response." Spell out every branch:

Says they'll pay today: confirm the amount, confirm the method, end the call
Asks for more time: ask for a specific date, log it as a promise to pay
Says they can't pay in full: offer only the options you've approved, nothing improvised
Disputes the debt: acknowledge it, log it, stop the collection conversation
Gets angry or asks for a human: transfer or schedule a callback immediately

An agent that only knows the goal, not the branches, tends to over-explain or loop when the conversation goes off script. In collections, an improvised offer is also a compliance risk.

Step 3: Connect your tools before you launch

The agent needs somewhere to send what happened. In DronaHQ that's the Tool Builder and Connector Library, with integrations like Google Sheets, Slack, Notion and Gmail, plus MCP and Composio for anything not natively supported.

Connect at least one destination before the first campaign. For collections that could be a sheet that logs every promise to pay, or an alert to your collections team when a borrower disputes or asks for a human. If you wire this up later, you spend that gap pulling outcomes out of call logs by hand.

If you want to send a payment link after the call, do it through a connected tool or webhook, and keep the payment itself in your existing payment system.

Step 4: Run a campaign

With the agent built and tools connected, set up the campaign:

Name it, pick the number to call from, and select the agent
Upload a CSV of accounts and map the columns to the variables the agent expects, like borrower_name, amount_due and due_date
Turn on auto-retry for unanswered calls, with a retry count and wait time
Set the timezone and calling window

The calling window matters more here than in most outbound use cases. Set it inside your legal hours, in the borrower's timezone, and treat it as a hard limit rather than a preference. Let auto-retry handle the people who miss the first call.

Also check that the agent is published before you launch. Campaigns only pull published agents and published changes, so a script edit you forgot to publish means the campaign runs on the old version without telling you.

Step 5: Watch the first batch

Open the Campaign Overview early and watch the pick-up rate on the first batch. If it's low, the calling window is usually off or a chunk of numbers in the CSV are bad. It's cheaper to catch that after twenty calls than after two thousand.

Then listen to a few transcripts. Check the calls marked completed, not just the failed ones, and read specifically for the disclosure, the tone when a borrower pushes back, and whether the agent stayed inside the offers you approved.

Post-call analysis: How to measure whether it's working

A transcript alone doesn't tell you whether a collections program is working. You need structured data from every call, in a place your team already looks.

The setup has four parts:

Structured output on the agent. Define a schema for the fields that drive a decision: disposition, promise-to-pay date, promised amount, dispute flag, sentiment. It runs as part of the call, so the data is ready when the call ends.
A post-call webhook. The agent fires it once the structured output is ready, so nobody opens a call log to check.
An automation that catches it. Write the fields into a database. A Google Sheet is fine to start, and a proper database makes sense once volume makes the sheet painful to query.
A dashboard on top. Once outcomes land in one place consistently, connect a dashboard so trends show up without exports.

For the payment reminder example, a completed call produces a record like this: disposition: promise_to_pay, promised_date: Friday, dispute: false, sentiment: neutral. That record can log a row in a tracking sheet and, if the borrower asked for a human, alert your team immediately.

Build this against a hundred calls a day, not after you're running several campaigns.

Metrics worth tracking from day one:

Connect rate: picked-up calls against total dialed
Disposition mix: paid, promise to pay, dispute, no answer, wrong number
Promise-kept rate: how many promises to pay turn into actual payments. This is the number that tells you whether the calls changed behavior.
Dispute and complaint rate: the early warning for compliance problems
Escalation rate: how often the agent hands off to a human
Cost per call: split across speech-to-text, the model, text-to-speech and structured extraction

Promise-kept rate is the one most teams skip. A call that ends in a promise looks like a win until nobody pays.

Voice agent vs. human team vs. autodialer

	Human collections team	Autodialer / prerecorded IVR	AI voice agent
Reach	Limited by headcount and shifts	Every account, one-way message	Whole portfolio, two-way conversation
Handling pushback	Strong, varies by person	None, dead-ends	Handles scripted branches, escalates the rest
Disclosure consistency	Varies by agent and day	Scripted, can't adapt	Same on every call
After-hours coverage	Needs extra staffing	Yes	Yes, inside legal hours
Data capture	Free-text notes	Keypress only	Structured, per call
Best for	Complex and sensitive accounts	Simple notices	Early-stage, high-volume, after-hours calls

The practical difference is that a voice agent gives you coverage and consistency on the volume work, and your humans keep the judgment work.

Failure modes to watch for

Calling outside the legal window: a timezone mismatch in the CSV is enough to cause it
No escalation path: a borrower who wants a human and can't reach one is worse than no call at all
Improvised offers: if the agent isn't told what it can offer, it may offer something you can't honor
Pressing after a dispute: a dispute should end the collection conversation and route to a person
Silent nulls treated as answers: a null field means "not mentioned," not "no"
Over-nested extraction schemas: start with three or four fields that drive a decision
Wrong person on the line: the agent shouldn't discuss the debt until it's confirmed who it's speaking to
No human spot-check loop: sample a small percentage of calls on a recurring basis, even once automation is live

Where humans still matter

Voice AI handles the repetitive first contact well. It handles hardship, grief, anger and complicated disputes less well, and those are the calls where a bad interaction does the most damage.

So design the handoff on purpose. Decide which signals trigger a transfer, whether that's a dispute, a hardship mention or a request for a person, and make sure a human gets the full context when they pick up. A borrower shouldn't have to repeat themselves.

Pre-launch checklist

Number connected and eligible for outbound use in its region
Calling hours, disclosures and consent reviewed by compliance or legal
Agent created, with voice, transcriber and LLM models selected
Instructions written branch by branch, first message tested with all placeholders
Escalation and dispute rules configured
Tools connected, with at least one wired to a real destination
Contact CSV prepared, columns mapped, and timezones verified
Auto-retry, attempt cap and calling window configured
Agent published before the campaign launches
Structured output schema defined (three to four fields to start)
Test call reviewed before the full campaign

Closing

Voice AI in collections works when the boring parts are in order: compliance settled first, instructions written branch by branch, and outcomes captured in a form your team can act on. The model's voice quality is rarely what decides it.

Start narrow. Pick one early-stage use case, like the seven-day payment reminder, check the first batch closely, and expand only once promise-kept rate and complaint rate both look healthy.

AI Agent Governance: A Practical Guide for Agents That Work in Production

Aharna Haque — Fri, 09 Oct 2026 07:21:12 +0000

AI agent governance is the set of rules, checks, and controls that decide what an autonomous agent is allowed to do, see, and act on once it's live. In one line: it's how you keep an agent accountable after you've stopped watching it every second.

TL;DR: If your agent only chats, governance can wait. If it books, refunds, updates records, or touches a real system, governance isn't optional, it's the thing standing between "cool demo" and "expensive incident."

Here's a real one. In early 2024, Air Canada's support chatbot told a customer he could apply for a bereavement fare after his flight, and gave him a made-up policy to back it up. Air Canada tried to argue the chatbot was "a separate legal entity" responsible for its own words. A Canadian tribunal didn't buy it. The airline had to honor the refund and pay damages. Nobody had reviewed what the bot was allowed to promise.

That's the whole problem in one paragraph. The agent wasn't malicious. It wasn't even that badly built. Nobody had drawn a line around what it could say and do, and when it crossed that line, there was no system catching it before the customer did.

Why This Matters Now

Two years ago, most "AI in production" meant a model scoring leads or flagging fraud. A human looked at the output before anything happened. That's not true anymore.

Agents today book calendar slots, issue refunds, write and merge code, update CRM records, and call other agents to finish the job. They act first and get reviewed later, if at all. When something breaks, it's not a wrong prediction sitting in a dashboard. It's a wrong action that already happened somewhere.

That shift is why governance built for predictive ML doesn't hold up here. You can validate a model once and monitor for drift. You can't validate an agent once and call it done, because the same agent can behave differently tomorrow based on a prompt change, a tool update, or a model version bump it didn't even ask for.

What Is AI Agent Governance, Really?

Strip away the framework language and governance comes down to three questions you should be able to answer for every agent running in your stack:

What is this agent allowed to do, and what happens the moment it tries to go past that?
If it made a bad call six months ago, can you reconstruct why?
Can someone stop it mid-action, not just after the fact?

If you can't answer all three, you don't have agent governance. You have a policy document and a hope.

This is different from AI governance in general, which covers the whole lifecycle of models and data. Agent governance is the sharper, more operational slice of that: it's specifically about systems that reason, decide, and act without asking permission on every step.

The Building Blocks of Agent Governance

Think of this less as a policy binder and more as a set of layers wrapped around every agent you ship.

1. Guardrails, Enforced at Runtime, Not Written in a Doc

An agent shouldn't be able to do something harmful just because nobody remembered to test that edge case. Guardrails need to be architectural:

Input controls — what data and instructions the agent can even receive
Process controls — confidence thresholds, required reasoning steps, mandatory checks before it proceeds
Output controls — what it's blocked from saying, leaking, or promising
Action controls — hard caps on what it can actually execute (transaction size, scope, rate)

2. Identity and Access, Like It's a New Hire With a Badge

Every agent should have its own identity, its own permissions, and its own owner. Not a shared API key three teams forgot about. If an agent touches customer records, it should have exactly the access it needs for that job and nothing left over "just in case."

3. Observability That Shows the "Why," Not Just the "What"

Logging that an agent issued a refund isn't enough. You need to see what it considered, which policy applied, how confident it was, and what it would have done differently with slightly different input. This is what turns "the agent messed up" into "the agent messed up because X, and here's the fix."

4. Human Checkpoints That Scale With Risk

Not every action needs a human in the loop. A low-stakes FAQ answer doesn't. A refund over a certain amount, or anything touching production data, should. Graduated autonomy, more oversight as the stakes go up, is the practical middle ground between "review everything" (too slow to matter) and "review nothing" (how Air Canada ended up in a tribunal).

5. A Kill Switch That Actually Works

When an agent starts behaving oddly, someone needs to be able to pause it, roll it back, or shut it down without a ticket, a deploy, and a prayer. If your only option is "wait for the next release," that's not a control, that's a delay.

6. Audit Trails That Don't Need to Be Rebuilt From Memory

When a regulator, a customer, or your own legal team asks "what did the agent do and why," the answer should already exist. Not reconstructed from Slack messages and someone's recollection three weeks later.

How Agent Governance Works

text

User request
   │
   ▼
Guardrail layer (input / process checks)
   │
   ▼
Agent reasons + selects tool
   │
   ▼
Action layer (scope + limits enforced)
   │
   ▼
Executes → logs decision + context → audit trail
   │
   ▼
Human review triggered if risk threshold crossed

Traditional AI Governance vs. Agent Governance

Category	Traditional Model Governance	AI Agent Governance
What's being governed	Predictions or scores	Actions taken on real systems
When review happens	Before deployment, periodically after	Continuously, sometimes mid-action
Who acts on the output	A human, usually	The agent, often without a human touching it
Failure looks like	A wrong number on a dashboard	A refund issued, a record changed, a message sent
Monitoring cadence	Scheduled drift checks	Real-time, behavior-level
Accountability	Usually the data science team	Spread across product, security, legal, and whoever owns the agent

Where It Actually Breaks in Production

Governance conversations get abstract fast, so here are patterns that keep showing up:

1. The Agent Did Exactly What It Was Told, and That Was the Problem

In 2025, an AI coding agent from Replit deleted a production database during what was supposed to be a code freeze, then fabricated data to hide it happened. It had access it never should have had, and no one had drawn a hard line around "you cannot touch production without a checkpoint."

2. Multi-Agent Chains Hide Where Things Went Wrong

When one agent retrieves data, another reasons over it, and a third takes action, a bad outcome can come from any link in that chain. Without visibility into the handoffs, teams end up debugging by guesswork.

3. Confidence Doesn't Mean Correctness

Agents that sound sure of themselves are the most dangerous kind of wrong. Grounding an agent in approved sources helps, but for anything consequential, that still isn't enough on its own, you need a threshold below which the agent has to stop and ask.

4. Nobody Owns the Agent Once It's Live

It got built, it got shipped, and then the person who built it moved to a different project. Six months later nobody can say who's responsible when it misbehaves.

What Good Governance Actually Buys You

This isn't just risk avoidance. Teams that build governance in early tend to move faster, not slower, for a simple reason: once the first agent has guardrails, identity, and audit trails figured out, every agent after it inherits that infrastructure. Approvals stop being a debate about "is this safe" and start being a checklist.

For a support, finance, or ops workflow, that translates to:

Speed — approvals happen in days because the controls are already proven, not re-argued for every new agent
Accuracy — confidence thresholds and human checkpoints catch bad outputs before they become bad actions
Verifiability — when something is questioned, you can show exactly what happened and why, instead of guessing
Stability — version pinning and rollback mean a model provider's update doesn't silently change your agent's behavior overnight

This shows up concretely in workflows like procurement approvals, HR screening, legal document review, and customer support, anywhere an agent's decision has a real downstream effect on a person or a contract.

What This Means for Enterprises

The teams getting this right aren't the ones with the most autonomous agents. They're the ones who can say, with evidence, exactly what every agent is allowed to do and what happens when it tries to go further. That's a quieter kind of maturity than "we shipped 40 agents," but it's the one that survives an audit.

The next stretch of this problem is multi-agent and multi-system governance, agents that call other agents, pull from multiple data sources, and make joint decisions no single log line explains. Individual agent guardrails won't be enough there. Governance will need to operate at the level of the whole workflow, not just the single agent, tracking how decisions move between systems and who's accountable when three agents disagree.

Where to Start

If you're deploying your first production agent, don't start with a governance framework document. Start with three things: give the agent its own identity, put a hard cap on what it can execute without a human checkpoint, and make sure every action it takes is logged somewhere you can actually query later. Everything else builds on top of that.

Agents that work in production earn trust the same way people do, by being predictable, accountable, and easy to check on. Governance is just the system that makes sure of it.

A guide to set up outbound AI voice agent for customer service

Aharna Haque — Thu, 08 Oct 2026 04:06:52 +0000

An outbound AI voice agent is software that places phone calls on a business's behalf, using speech recognition and generative AI to hold a real conversation instead of playing a fixed script. This guide walks through setting up an outbound AI voice agent end to end, using the AC service follow-up example throughout, and covers how to tell whether the calls are actually working once they're live.

What is an outbound AI voice agent?

An outbound AI voice agent places calls instead of waiting for a customer to call in. It's triggered by an event in another system—a CRM update, a rejected service ticket, a scheduling change—and it calls the customer with a defined goal.

This is different from an inbound agent, which answers calls that come in. It's also different from a traditional IVR or auto-dialer, which plays fixed menus or pre-recorded messages and can't handle an open-ended answer.

Common enterprise use cases include:

Appointment reminders and confirmations
Billing and payment follow-ups
Post-service surveys and re-engagement calls
Lead outreach and qualification

The AC service example used throughout this guide falls into the third category: a post-service re-engagement call that confirms whether the customer still needs help.

The customer service example: A post-service feedback call

Here's the scenario. A field team rejects a customer's air conditioner service request—the part wasn't in stock, or the technician had to reschedule. Instead of the request sitting untouched, an outbound AI voice agent calls the customer directly: is the service still needed, or has it been handled another way?

This is a good first use case for outbound AI because it's low-stakes, structured, and happens at volume. The agent doesn't need to negotiate a contract or resolve a billing dispute; it needs a yes, a no, or an escalation. That's easy to script, easy to test, and easy to measure.

Prerequisites before you start:

Before configuring anything, have two things ready:

A phone number the agent will call from, connected through your platform or a SIP trunk
Agent instructions—the opening line, the goal of the call, and what the agent should do if the customer asks for a human

Everything else in the setup builds on these two.

Step-by-Step Setup Guide

The steps below are platform-agnostic, but the specifics are shown using DronaHQ's voice agent as the working example.

Step 1: Connect a Phone Number and Create the Agent

Start inside DronaHQ's voice agent builder and connect telephony through a SIP trunk. A Twilio Elastic SIP Trunk works if you already run call infrastructure on Twilio. Once the trunk is connected, the number shows up in the platform's Phone Numbers list, and you route it to your agent under Call Configuration → Outbound Settings.

From there, go to the admin console and click Create Agent.

Important: Each phone number is tied to one agent and one live call at a time. If you're planning to call a large customer list in a short window, you'll want more than one number, or the campaign will just take longer to work through. Figure out your expected call volume before you commit to a single number.

Step 2: Configure the Agent and Write the Instructions

With the agent created, set up the core pieces:

Voice model
Transcriber model
LLM model
Agent instructions
First message

The first message can be static, but for anything customer-facing, use placeholders instead. A generic opener sounds like a robocall the second the customer hears it.

Something like:

"Hi {{customer_name}}, this is {{company_name}} calling about your air conditioner service request. We wanted to check, is the service still needed, or has this been resolved?"

works better because it names the customer and the actual request, so the call feels like a real follow-up instead of a mass dial.

For the instructions, don't just write "handle the customer's response." Spell out each branch explicitly:

What to say if they say yes
What to say if they say no
What to do the moment they ask for a person

Agents that are only told the goal of the call, without the branches, tend to over-explain or loop back on themselves when the conversation goes slightly off script. Writing out the branches ahead of time avoids that.

Step 3: Add Your Tools

The agent needs access to the systems that hold customer data or receive call outcomes, usually through a webhook or a set of connected tools.

In DronaHQ, this is the Tool Builder and Connector Library, with pre-built integrations with tools like Google Sheets, Slack, Notion, and Gmail, plus broader access through MCP and Composio for anything not natively supported.

Connect at least one destination before you launch anything, not after. It's tempting to run a campaign first and wire up Slack or a tracking sheet later, but then you're stuck manually pulling outcomes from the call logs for however long that gap lasts.

For the AC example, connect a Slack channel or a tracking sheet upfront, so every call outcome lands somewhere your team can act on it immediately.

Step 4: Run a Campaign

With the agent built and tools connected, set up a campaign to actually place the calls:

Name the campaign, pick the phone number to call from, and select the agent.
Upload a CSV of contacts—in this case, the customers whose AC service request was rejected.
Map CSV columns to the variables your agent expects, like mobile_number or customer_name.
Turn on auto-retry for unanswered calls, and set retry count and wait time between attempts.
Set a timezone and a calling window.

That calling window matters more than it looks. As someone running a customer support team, you'd want the agent calling during hours when people are actually awake and likely to pick up, not at 6 AM or late at night.

Set the window to something like 9 AM to 7 PM in the customer's timezone, and let auto-retry pick up the ones who miss the first call instead of trying to time everything perfectly on the first attempt.

Also, double-check the agent is published before you launch. Campaigns only pull in published agents and published changes, so if you tested a script tweak and forgot to publish it, the campaign runs on the older version without telling you.

Step 5: Check the Results

Once the campaign is running, don't just let it finish and check back later. Open the Campaign Overview page early and watch the pick-up rate for the first batch of calls.

If it's unusually low, that's often a sign the calling window is off, or a chunk of numbers in the CSV are bad. It's cheaper to catch that after twenty calls than after two thousand.

The overview gives you:

Total calls
Ended calls
Pick-up rate
Voicemail count
Call-by-call logs
Recordings
Transcripts
End reasons
Cost per call

Spot-check a few transcripts on calls marked as completed, not just the failed ones, to confirm the agent is actually closing conversations the way you intended, not just technically finishing them.

For the AC example, this is where you'd see how many customers:

Confirmed the service was still needed
Said it was resolved
Didn't pick up

—and you can do that without listening to a single call yourself.

Post-Call Analysis: How to Measure Success

Setting up the agent and running the campaign is half the work. The other half is what happens after each call ends, and this is where most outbound AI evaluations fall short because a transcript by itself doesn't tell you whether the program is working.

Post-call analysis is best understood as four layers, each doing a different job:

1. Transcripts

A turn-by-turn record of what was said, plus a technical log—connection time, agent decisions, system events—used to debug when something goes wrong.

2. Tool Integration

Routing the outcome of a call into the systems your team already uses, like a Slack alert or a Google Sheets row, without anyone copying data by hand.

3. Structured Extraction

Pulling defined fields out of the conversation, like disposition, reject reason, and sentiment, using a fixed schema instead of free-text notes.

4. Analysis

A dashboard built on top of that structured data, so trends show up without exporting anything.

Applied to the AC service example, every completed call produces a structured record such as:

disposition: service_still_needed
reject_reason: part_unavailable
sentiment: neutral

That record can trigger a Slack alert to the field-service team or log a row in a tracking sheet automatically.

How to Wire It Up

Here's how to actually wire that up instead of leaving raw transcripts sitting in the call log:

Define structured output on the agent.

Set up a schema for the fields you actually want to extract: disposition, reject reason, sentiment, or whatever drives a decision downstream. This runs as part of the call, not as a separate step, so the data is ready the moment the call ends.

Set up a post-call webhook.

Have the agent fire a webhook once the call ends and the structured output is ready, instead of someone opening the call log to check. This is what turns "the data exists somewhere in the platform" into "the data shows up where you need it."

Connect an automation to catch it.

Point that webhook at an automation that runs on receipt, and have it write the structured fields into a database. A Google Sheet works fine to start—it's low effort and everyone on the team already knows how to open it. Move to a proper database once volume makes a spreadsheet painful to query.

Spin up a dashboard on top of that data.

Once outcomes are landing in one place consistently, connect a dashboard to it. This is where connect rate, disposition mix, and reject reasons over time actually become visible, instead of numbers you'd have to calculate by hand from the call log each week.

Do this before you scale up call volume, not after. It's a lot easier to build the pipeline against a hundred calls a day than to retrofit it once you're running multiple campaigns and nobody's tracking outcomes consistently.

Metrics Worth Tracking From Day One

Connect rate: Picked-up calls against total calls dialed
Disposition mix: Service still needed, resolved elsewhere, no answer, wrong number
Reject reasons: Grouped and counted to spot recurring operational problems
Sentiment trend: Flagging calls that need a human follow-up
Cost per call: Broken down by speech-to-text, the core model turn, text-to-speech, and structured-output extraction, since extraction runs as its own line item and adds up at volume

Manual QA vs. a Structured Post-Call Stack

Dimension	Manual Call Review	Structured Post-Call Analysis
Transcript availability	Often audio-only, transcribed on request	Every call, turn by turn
Time to insight	Hours to days	Seconds after the call ends
Coverage	A sample of calls	100% of call volume
Routing to other tools	Manual copy-paste	Automated via connected tools
Data format	Free-text notes	Structured, consistent fields
Dashboard	Rebuilt from exports each time	Built once, reused ongoing

The practical difference is coverage. Reviewing a sample of calls was always a compromise. A structured pipeline reviews all of them, which matters most in workflows where a missed rejection reason has a real operational cost.

Outbound AI Voice Agent vs. Manual Calling vs. Traditional IVR

Dimension	Manual Call List	Traditional IVR / Auto-dialer	Outbound AI Voice Agent
Setup effort	Low, but ongoing staffing cost	Moderate, fixed menu logic	Moderate, instructions + integration setup
Personalization	High, but inconsistent	None, fixed prompts only	High, placeholder-driven and dynamic
Cost at scale	Scales with headcount	Cheap per call, low value	Scales with usage, not headcount
Escalation handling	Native, it's a human	Poor, dead-ends often	Configurable transfer rules
Data capture	Manual notes, inconsistent	Minimal, keypress-based	Structured, per-call, automated

Failure Modes to Watch For

Missing mapped fields at campaign setup: If a CSV column isn't mapped to a variable the agent expects, the call breaks or sounds off.
No escalation path configured: A customer who wants a human hits a dead end, which is worse than not calling at all.
Over-nested extraction schemas: Asking for too many structured fields per call increases the chance of partial or malformed output. Start with three or four fields that actually drive a decision.
Silent nulls treated as answers: A null field means "not mentioned," not "no." Dashboards that conflate the two will misreport outcomes.
Ineligible numbers used for outbound: Some countries restrict mobile numbers for automated outreach. Check regional rules before adding a number.
No human spot-check loop: Even with automation live, sample a small percentage of calls for manual review on a recurring basis.

What This Means for Enterprises

Voice AI is moving from a channel that talks to one interface into a larger agentic workflow. The call itself is rarely where the value shows up; it's what happens right after: a record updated, a team alerted, a request closed out, without anyone touching a spreadsheet.

That shift also changes what's worth measuring. Instead of aggregate stats like average handle time, teams get semantic data:

Why customers say no
Which reject reasons keep recurring
Where sentiment turns negative

The next step past this is agentic follow-through, where a structured call outcome doesn't just populate a dashboard—it triggers the next action automatically, whether that's a re-dispatch, a refund check, or a CRM update.

Pre-Launch Checklist

[ ]Phone number connected and eligible for outbound use in its region
[ ]Agent created, with voice, transcriber, and LLM models selected
[ ]Agent instructions written and first message tested, including any placeholders
[ ]Escalation rules and voicemail handling configured
[ ]Tools connected, with at least one wired to a real destination (Slack, Sheets, or similar)
[ ]Contact CSV prepared and columns mapped to agent variables
[ ]Auto-retry and calling window configured
[ ]Agent published before the campaign is launched
[ ]Structured output schema defined (three to four fields to start)
[ ]Test call reviewed before running the full campaign

Closing

Setting up an outbound AI voice agent isn't complicated once the pieces are in order: a number, agent instructions, a few tools, and a campaign to run it against.

What separates a working program from a stalled one is usually what happens after the calls—whether the outcomes are structured enough to act on.

Start narrow, with one use case like the AC service follow-up, check the results, then expand.

If you're building this out further, the next useful read is how to measure ROI on voice AI programs once they're past the pilot stage. Voice agents will keep getting better at holding a conversation; the bigger gap, for most enterprises, is still what happens in the seconds after the call ends.

Build your first AI agent

Aharna Haque — Thu, 27 Nov 2025 08:05:27 +0000

Over the past year, the conversation around AI inside enterprises has shifted. Teams are no longer asking whether AI can help with individual tasks—they're asking how AI can act on their behalf, move work forward, and make decisions without constant supervision. This is where agentic AI comes in.

Agentic AI refers to systems that can observe what's happening, reason about the situation, take action, and learn from the outcome. Instead of waiting for a prompt, these agents proactively handle multi-step, often messy workflows—checking data, following policy, coordinating across systems, and asking for approval only when needed. It's a clear step beyond traditional generative AI, which is powerful but fundamentally reactive.

Why you should care?

For developers, this is your moment.

While enterprises care about reducing delays and improving consistency, you have an opportunity to be at the forefront of this shift. Agentic AI lets you automate the tedious work that's been eating away at your time—data validation, cross-system orchestration, repetitive API calls, status updates—all the glue code that keeps you from building what actually matters.

But here's the bigger picture: in the current AI agent hype cycle, you can build something genuinely impressive. This isn't just another chatbot or autocomplete feature. You can create systems that autonomously handle complex workflows, make intelligent decisions, and deliver real business impact. The kind of work that makes stakeholders stop and take notice.

This is your chance to rise to the pressure, deliver that "wow factor" at work, and position yourself as someone who doesn't just follow trends—but implements solutions that transform how your organization operates.

Build and ship your first AI agent

We've created a hands-on workshop on AI agents designed for the enterprise, and you can register to join us.

The focus is practical: how to apply agentic AI to your day-to-day systems in a way that's controlled, reliable, and immediately useful.

You'll walk away knowing how agentic AI works, where it creates value, and how to deploy it responsibly inside your organization.

See you there!

Build an app with Veda AI + DronaHQ

Aharna Haque — Thu, 14 Aug 2025 04:55:29 +0000

Hey folks! 👋

Last week, I ran a live workshop showing how you can build a fully functional HRMS onboarding app—backed by MySQL—using Veda AI inside DronaHQ. And no, we didn’t spend hours manually designing screens or writing SQL queries. We used screenshots and plain English prompts to build 80% of the app in minutes. 🙌

Here’s a step-by-step guide if you want to build along!

P.S.- I have attached the video of the live workshop (in case you want to check that out)

What you’ll learn

How to connect your own database
Generate UI from a screenshot (yep, seriously)
Bind data with a single prompt
Autogenerate forms from existing DB tables
Add actionflows using plain English
Master server-side pagination
🎁 Bonus: Apply a theme with one sentence

Before you start

Make sure you’ve got:

✅ Signed up on DronaHQ
✅ Access to DronaHQ Studio
✅ Drive link for images
✅ Create a MySQL Database with an employees table. You can use the SETUP doc for data queries, or watch the workshop video for a step-by-step walkthrough on how to add a Connector.

Goal: build an employee onboarding CRUD app

Let’s jump in!

Step 1: Create a new app

Head to DronaHQ App Builder
Create a new App in the builder.
Find Veda AI in the left sidebar
Click to open it. A chat section will open on the left side.

Step 2: Generate UI from screenshot

For this apllication we are going to let Veda AI do the heavy lifting for us. You can upload screenshots, Figma exports, or even hand-drawn wireframes to generate upto 80% of the UI in seconds.

📂 Use this sample image from the provided drive link.

Design files to UI with Veda AI

Your layout is ready. No drag and drop. No hustle.

Step 3: Bind data to a table

Goal here is to display the employee data in the table. To do that hover over your Table control, click on Veda AI Assist, and say:

"Bind employee data from @<DBname> <tablename>"

You can either use the query it suggests (dont forget to select the right database and the table) or navigate to Data query section → New → Connect Library → Select Database and paste this query:

SELECT * FROM <tablename>;

Pro tip: Veda AI understands your schema. You can chat with it about your DB!

Step 4: Autogenerate form

Next, we would like to insert new employee information to our existing database table. DronaHQ provides options to autogenerate forms for your table in just a few clicks.

Autogenerate Form

Navigate to Screens → Click on "+" → Select "Tray". A new tray would be created. We will not be using the templates here, instead we will select Autogenerate Forms option on the tray.
Choose your connector → table → Add Insert on click of submit → Generate Form

And bam! You get a fully wired CRUD form—ready to insert new employees into your DB.

Step 5: Add server-side pagination (for big data)

We want smooth performance when your data grows. Server-side pagination in DronaHQ lets you filter and load data directly from the backend.

Go to:
Data Queries → New → Connect Library

Pick your MySQL DB and run this query:

SELECT employee_id, name, email, phone, department, designation  
FROM <tablename>  
WHERE {{tablegrid.PROPERTIES.FILTERQUERY}}  
LIMIT {{tablegrid.PROPERTIES.LIMIT}}  
OFFSET {{tablegrid.PROPERTIES.OFFSET}};

✅ Important:
Turn ON “Server-side pagination” from the Table’s Properties Toolbar.

Step 6: Show total employees count

To display a count on top of your dashboard and add data query:

SELECT COUNT(*) as total FROM <tablename>;

Bind this to a Stats Card or Text Label control, and you’ve got live metrics.

Bonus: Apply custom UI theme in seconds

DronaHQ offers quick theme configuration across your app, easily managed through the console.
Just navigate to top-right to Setting icon → Themes → Choose your themes

Incase, you want to edit the themes configuration, head over to your Admin console → Account Settings → Themes Configuration

Set your themes configuration
Fonts, spacing, and colors—done. No manual tweaking needed.

Congratulations! Your application is ready

Your application should now look like this. You can continue building by adding other live metrics and more features.

Your application is ready!

Why Veda AI + DronaHQ is a game changer

80% of your app is ready in minutes
No code lock-in — generated UI maps to editable controls
Conversational UI & logic building — you prompt, it builds
Enterprise-ready — RBAC, SOC2, audit logs, theming guardrails

Final thoughts

It was awesome watching attendees go from a single screenshot to a production-grade UI—no SQL wrangling, no painful UI design.

Just prompts, fast feedback, and real results.

Try Veda AI today!

UX Web Components: 101 for Frontend Developers & Designers

Aharna Haque — Thu, 03 Jul 2025 17:52:48 +0000

🚩Thinking about diving into frontend dev or design? You didn’t land here by mistake — this is your SIGN.

Here's what you'll be learning:

Spending hours over making your website responsive and achieve uniformity?

You are not alone :)

To achieve web uniformity and responsiveness across different devices, browsers, accessibility, performance, and async states- complexities in the frontend have only risen leading to building 10s and 100s of UI. Relatable?

This problem everyone can relate to while building anything from a simple portfolio website → enterprise level website.

Amidst all that, think what inconsistent styling, poor accessibility, fragile API, unpredictable performance, A shadow-DOM button that ignores theme fonts, a component lacking keyboard focus—bulk UI debt can do to your impact.

As frontends scale, even with component-driven tools like React, Vue, or Angular, you often end up with hundreds of components and thousands of variations—adding complexity rather than eliminating it.

Web Components: Your Solution🧪

"Web Components" is an umbrella term that refers to a collection of web standards focused on enabling the creation of custom HTML elements. ~ Microsoft

Web Components can be a savior in these scenarios which also roots for your long-term consistency and performance.

Web Components in UX are Custom Elements + Shadow DOM that provide encapsulation, reusability, and a clean API. Three main elements in web components-

Custom Elements: JavaScript APIs that let you define your own HTML tags and behaviors for use in your UI.
Shadow DOM: A JavaScript API that attaches a private, encapsulated DOM subtree to an element, allowing isolated scripting and styling without affecting the rest of the document.
HTML Templates: The and elements provide reusable chunks of markup that remain hidden until they’re instantiated, often inside custom elements.

Heard of these Companies? Yes, they use web components too😉

You can check out this video by Cassondra Roberts, Staff Design Engineer, Adobe for Shadow DOM

Major Web Components Gains:📈

Highly customizable with custom elements and HTML templates.
Deploy them across mobile, desktop, web devices.
High Framework-agonistic: use Web Components with any of these frameworks like React, Angular, Vue.

Web Components also has some Trade‑Offs:📉

Web Components' reliance on browser-specific APIs and Shadow DOM complicates their server-side rendering, making cross-framework SSR integration challenging.
Encapsulation via Shadow DOM can hinder proper ARIA attribute application and focus management, necessitating meticulous planning for accessibility.
Web Components may introduce lock-in issues with meta-frameworks, bundlers, and testing tools, and may not seamlessly integrate with existing frameworks like React or Vue

Design System == Your Blueprint 🌐

Think of it as a blueprint that helps to keep the product look and feel uniform and consistent.
It is a central library of components, style guides, accessibility guidelines—serving as a single source of truth. It streamlines workflow and accelerates development process with design tokens.

Quick FAQ: Design tokens are small, reusable design decisions that make up a design system's visual style.

Here is a guide by Figma on building Design Systems

Your mantra if you're starting out

Wireframe Components → build template + Shadow DOM prototype → test

Enter Storybook: Design System Catalyst

Recently I came across Storybook is an open-source UI component workshop—a development environment where you build, test, showcase, and document your web components in isolation, away from the complexity of your full application

Each component in Storybook is accompanied by "stories"—interactive examples that showcase different states and configurations. These stories serve as both documentation and test cases.

In essence, Storybook transforms your UI components into self-contained units that are easier to develop, test, and maintain, all while fostering better collaboration and communication within your team.
Read more about Storybook and how to get started

UX Maturity Journey for Different Stage Enterprises:

Immature Stage:

Team Setup: No UX, solo dev/design

What it's like:

UX isn’t planned—features jump straight to code.
You're coding blind—no wireframes, A/B tests, or user research.
No user feedback or research; decisions are based on guesses
You patch UI issues reactively when bugs or complaints emerge.

Tip: If you’re here, you could practice these to bring in clarity

Easy first steps:

Start by asking: Who is this for? What’s the problem?
Do quick guerrilla tests—grab 3–5 users to watch them try a flow
Install a basic analytics tool (Hotjar/Clarity) to see click patterns.

Emergent Stage:

Team Setup: UX advocate + dev + product (less sync)

What it's like:

UX flows feel baked into sprint planning.
There's a basic design system and shared components
Build wireframes → prototypes → test & iterate.
Use storybook/design tokens for consistency.
Use simple UX metrics: onboarding completion, task time.

Matured Stage:

Team Setup: UX cross teams + dev + product in sync

What it's like:

UX drives strategy—not just features
Design system is robust; UX team involved early.
You’re shipping experiences users love, efficiently and iteratively.
Metrics like NPS, task success are part of your dashboards.
Code is maintainable, with reusable components and animations that reinforce UX.
Continuous discovery—user feedback feeds product roadmap.

Best Practices CheckList: ✔️

☑️ Define target audience. Ask: Who’s using this component? What problem does it solve?
☑️ Start small by designing mockups for your custom elements or basic usability tests(3-5 folks clicking through)
☑️ Normalize UX in your sprint. Add UX checklist before dev.
☑️ Use shared UI code.This is where you start building your web components.
☑️ Measure impact. Track signup flow time, onboarding drop-offs, NPS scores, onboarding completion rate, satisfaction scores. This will help you to zero in on the areas where users drop-off.
☑️ Share wins. Show how fixing one UX bug improved conversions—turn dev effort into product impact.

Other Resources You Can Check Out:

Shoelace is a gold standard of web component libraries. You can also check out best practices at Shoelace
Spectrum Web ComponentsAdobe’s Design System, web component flavored.
Another great general list of best practices.

Special thanks to @debajit13 for feedback on a draft of this blog post.

[Boost]

Aharna Haque — Tue, 17 Jun 2025 12:39:51 +0000

Ultimate Guide to Admin Roles & Access 2025

Aharna Haque ・ Jun 17

#webdev #frontend #tooling #community

Ultimate Guide to Admin Roles & Access 2025

Aharna Haque — Tue, 17 Jun 2025 09:24:00 +0000

Why Admin Access Needs to Be a Fortress?

At a rapidly growing startup, an eager intern was granted "Admin" access to the admin panel for training purposes. In an attempt to make a difference, they unintentionally erased important user data, which resulted in a brief system outage.

This incident shows the importance granting least permission as per requirement of the user role.

In the digital age, where admin panels act as command centers for businesses, scalability and security must be guaranteed.

Real-world risks of poor access controls:

Data breaches by accounts with deep access.
Internal sabotage by a discontent employee.
Unintentional or accidental errors
Compliance failures with various regulations like GDPR, HIPAA, or SOC 2

The 3 Pillars of Role-Based Access Control(RBAC):

To keep the system secure and agile, RBAC (Role-Based Access Control) is the go-to framework. Here's how to build it right:

1. Define the roles first:👩‍💻

Admin: Has full access to all setting and data.
Editor: Can create/modify but not change system settings.
Viewer: Has Read-only access to data

2. Implement the Principle of Least Privilege

This principle is about granting users minimum level of access necessary to perform their intended task minimises potential risks.

Less Privilege = Smaller Attack Surface

3. Make it Modular and Scalable:

As businesses grow, roles evolve. Regularly reviewing and adjusting permissions as roles evolve by granting granular permissions (like building blocks)

Here's Your Checklist: ✅

☑️ Implement Role-Based Access Control (RBAC)
☑️ Enable Multi-Factor Authentication (MFA)- add a critical layer of protection.
☑️ Secure Session Management: Enforce auto-logout on inactivity and limit session lifetimes.
☑️ Use Fine-Grained and Granular Permissions
☑️ Conduct Regular Access Reviews

We understood the "what", "why" and "how" of the security-- Time to narrow down on the platforms we can trust!

🔧Low-Code & Internal Tool Builders:

DronaHQ- Low-code platform with granular role-based access, UI-level permissions and enterprise-grade security and drag-drop features.
Retool- Internal tool build with RBAC, query level controls with SSO/MFA support.
Appsmith- Open-source tool for build admin panels with role management and authentication options.

👜Developer-Focused Admin frameworks:

Forest Admin- Plug-in and play admin panel with built-in access control, logs and permissions protocols options.
Hasura – Real-time GraphQL engine providing API-level role-based and row-level permissions support.
Supabase – Firebase alternative with built-in authentication and secure row-level access control.

🔐 Authentication & Identity Management

Auth0 (by Okta) – Adaptable authentication and authorisation platform with SSO/MFA support.
AWS Cognito – Scalable AWS-native user auth for web and mobile application with Authentication, Identity management, Access control and Compliance check.

DEV Community: Aharna Haque

I built a WhatsApp AI agent in under 60 minutes, with low-code agent builder

The use case

How I chose an agent builder

Why I chose agent over automation for workflows in WhatsApp (quick primer)

What my WhatsApp-triggered agent actually does

Real-world use cases for WhatsApp AI agents (clinics, restaurants, salons, more)

How I built it

Step 1: Set up the WhatsApp trigger and AI instructions

Step 2: Build the knowledge base

Step 3: Configure intent detection (pricing, booking, reschedule)

Step 4: Connect Google Calendar for automated bookings

Step 5: Add email and WhatsApp confirmations

Step 6: Configure staff notifications (Slack, email, WhatsApp)

Step 7: Design the visual conversation flow

Step 8: Test and deploy

What I didn't have to do

The operational shift

The automation frontier nobody built yet

Cost, time, and build-vs-buy for WhatsApp AI agents

What happens next

Frequently asked questions

How do I build a WhatsApp AI agent without coding?

Can I build a WhatsApp AI agent in under 60 minutes?

What's the difference between a WhatsApp chatbot and a WhatsApp AI agent?

What tools do I need to build a WhatsApp AI agent in DronaHQ?

Can I use this WhatsApp AI agent for bookings, pricing, and reschedules?

How to use AI voice agents for debt collection: A practical guide

Why collections is moving to voice AI

The example: An early-stage payment reminder

Compliance comes first

Before you start: What you need

Step-by-step setup guide

Step 1: Connect a number and create the agent

Step 2: Write the instructions branch by branch

Step 3: Connect your tools before you launch

Step 4: Run a campaign

Step 5: Watch the first batch

Post-call analysis: How to measure whether it's working

Voice agent vs. human team vs. autodialer

Failure modes to watch for

Where humans still matter

Pre-launch checklist

Closing

Related reading

AI Agent Governance: A Practical Guide for Agents That Work in Production

Why This Matters Now

What Is AI Agent Governance, Really?

The Building Blocks of Agent Governance

1. Guardrails, Enforced at Runtime, Not Written in a Doc

2. Identity and Access, Like It's a New Hire With a Badge

3. Observability That Shows the "Why," Not Just the "What"

4. Human Checkpoints That Scale With Risk

5. A Kill Switch That Actually Works

6. Audit Trails That Don't Need to Be Rebuilt From Memory

How Agent Governance Works

Traditional AI Governance vs. Agent Governance

Where It Actually Breaks in Production

1. The Agent Did Exactly What It Was Told, and That Was the Problem

2. Multi-Agent Chains Hide Where Things Went Wrong

3. Confidence Doesn't Mean Correctness

4. Nobody Owns the Agent Once It's Live

What Good Governance Actually Buys You

What This Means for Enterprises

Where to Start

A guide to set up outbound AI voice agent for customer service

What is an outbound AI voice agent?

The customer service example: A post-service feedback call

Prerequisites before you start:

Step-by-Step Setup Guide

Step 1: Connect a Phone Number and Create the Agent

Step 2: Configure the Agent and Write the Instructions

Step 3: Add Your Tools

Step 4: Run a Campaign

Step 5: Check the Results

Post-Call Analysis: How to Measure Success

1. Transcripts

2. Tool Integration

3. Structured Extraction

4. Analysis