Inspiration
Call Aunty began with a simple idea: people already have the information needed for outreach, but turning that information into a useful phone conversation is still difficult.
A contact may live in Google Sheets, Airtable, HubSpot, or another system. An event may arrive through n8n, a form, a webhook, or a scheduled workflow. What is usually missing is the conversational layer that can contact the person, have a natural interaction, ask questions, understand the response, save the result, and determine what should happen next.
Call Aunty was designed to bridge that gap.
Instead of asking users to understand APIs, MCP, n8n nodes, phone infrastructure, or workflow configuration, Call Aunty starts with a simple question:
What do you want Call Aunty to accomplish?
A user can say:
“Call my survey participants and ask five questions.”
“Call guardians when a student is absent and record the reason.”
“Call new HubSpot contacts and ask whether they want a callback.”
“Call the people in my Google Sheet and collect feedback.”
The AI agent turns that intent into a structured workflow.
The inspiration also came from the realization that phone calls are different from ordinary automation. A database update is usually deterministic. A conversation is not. Someone can answer in unexpected language, refuse to answer, request a callback, ask a question, interrupt the conversation, or provide an ambiguous response.
That means Call Aunty needs more than a phone API. It needs conversation state, reasoning, policy controls, retries, recovery, and observability.
The project therefore evolved around a central pattern:
source → decide → authorize → converse → extract → update → escalate
This pattern can support surveys, callbacks, follow-ups, reminders, feedback collection, absence workflows, and other forms of structured outreach.
Another major inspiration was AI-agent automation. Traditional automation works well when every step is known in advance. An AI agent can interpret intent, choose tools, understand responses, handle branches, and adapt to the conversation.
Call Aunty combines that flexibility with deterministic systems such as n8n and CALL-E.
The AI agent provides reasoning.
n8n provides workflow orchestration.
CALL-E provides phone execution.
External systems remain the systems of record.
That combination became the core of the product.
What it does
Call Aunty is an AI-agent-driven phone automation platform built around CALL-E and n8n.
A workflow can start from a spreadsheet row, CRM change, form submission, webhook, schedule, absence event, callback request, or another automation.
The system determines:
- who should be contacted
- whether outreach is allowed
- what should be said
- what questions should be asked
- what branches should occur
- what information should be captured
- what happens after the conversation
The AI assistant acts as the front door.
A natural-language request is converted into a structured workflow intent containing things such as the contact source, trigger, call objective, questions, branches, outputs, and follow-up actions.
Call Aunty treats external actions explicitly. A real phone call is not considered a harmless internal operation. It can reach a real person and therefore requires validation and policy checks before execution.
The system can check:
- contact existence
- phone-number validity
- configured consent requirements
- do-not-contact restrictions
- calling windows
- required approvals
- action permissions
The CALL-E layer handles the phone operation while Call Aunty manages the surrounding workflow.
The architecture supports planning, execution, status monitoring, events, cancellation, and MCP-based tool access.
For surveys, Call Aunty treats the conversation as structured state rather than a static script.
A survey can contain:
- an introduction
- a consent step
- ordered questions
- conditional follow-ups
- skip/refusal behavior
- completion criteria
- answer storage
- post-call actions
Answers can be preserved in both raw and normalized forms.
For example, a respondent might say:
“It was pretty good, maybe a four.”
The workflow can retain the original response while storing a normalized rating of 4.
The system also tracks state such as:
- contact ID
- call ID
- run ID
- workflow execution ID
- survey session ID
- idempotency key
- attempt number
- question index
- completion state
This allows conversations and workflows to resume safely.
Error handling is another major capability.
The system distinguishes between conditions such as:
- busy
- no answer
- voicemail
- invalid number
- timeout
- rate limit
- authentication failure
- provider outage
- policy block
- duplicate request
- partial survey
- webhook failure
Not every problem should be retried.
A timeout may mean a call was actually accepted.
A duplicate request should not create another call.
A policy block should not be retried.
A partial survey may be better resumed than restarted.
This is why the recovery engine uses state-aware decisions.
Call Aunty also connects with operational tools including:
- Google Sheets
- Airtable
- HubSpot
- Slack
- Zapier
- n8n
- MCP
- CALL-E
The user can therefore build workflows where contact data enters from one system, a CALL-E conversation occurs, and the result is written back into another system.
For example:
Google Sheet → policy check → CALL-E → survey → update Sheet → Slack summary
Or:
HubSpot → eligibility check → CALL-E → response extraction → HubSpot update → follow-up task
The visual layer makes those workflows easier to understand.
A dashboard can show:
- calls attempted
- calls completed
- survey completion
- active calls
- failures
- callbacks
- escalations
- provider status
Individual conversations can show their current state, questions asked, answers captured, result, and next action.
The project also includes extensive synthetic datasets and replay scenarios for safe testing. These cover successful calls, partial calls, refusals, callbacks, provider failures, webhook duplication, policy blocks, and recovery states without contacting real people.
How we built it
Call Aunty was built as a layered system.
The transport layer communicates with external services such as CALL-E.
The policy layer determines whether a contact and action are eligible.
The idempotency layer prevents duplicate side effects.
The state layer tracks calls, surveys, workflow runs, and recovery transitions.
The AI-agent layer interprets natural-language requests, plans actions, selects tools, and handles conversation decisions.
The integration layer adapts external systems such as HubSpot, Airtable, Sheets, Slack, and Zapier to the Call Aunty data model.
n8n acts as the workflow execution and orchestration environment.
The survey engine handles questions, branches, answer extraction, partial completion, callbacks, and completion rules.
The fallback layer handles failures and determines whether the next action should be retry, wait, poll, resume, cancel, skip, or escalate.
Observability records state transitions, attempts, outcomes, failures, and key identifiers.
The visual layer presents those states as dashboards, tables, timelines, survey progress views, and operational widgets.
The architecture is intentionally modular.
A contact provider should not need to understand phone execution.
CALL-E should not need to know whether a contact came from Sheets or HubSpot.
The AI agent should not directly implement every external API.
Instead, each layer has a focused responsibility.
A simplified flow is:
Intent
→ Plan
→ Policy
→ Idempotency
→ Execution
→ Conversation State
→ Extraction
→ Persistence
→ Notification
→ Observability
→ Recovery or Completion
A major design principle is separating live integrations from mock data.
Live integrations use environment-based configuration and credentials.
Synthetic scenarios use fictional identities and reserved test phone numbers.
This allows the same workflow logic to be evaluated without accidental real-world outreach.
Testing includes:
- TypeScript checks
- build checks
- integration contracts
- state transition tests
- workflow validation
- replay scenarios
- mock API/MCP fixtures
- failure recovery tests
The project also includes n8n workflow templates so users can start from an existing structure instead of building every node from scratch.
Challenges we ran into
The biggest challenge was making the system reliable when external actions are involved.
A request can time out after a provider has already accepted it. Blindly retrying could create a duplicate call.
That led to the rule:
When an existing CALL-E run may already exist, check or resume that run before creating another call.
Another challenge was the difference between AI planning and authorization.
The agent may decide that a call is useful, but usefulness does not mean permission.
That required explicit policy gates for consent, do-not-contact status, calling windows, approval requirements, and other constraints.
Conversation ambiguity was another challenge.
People rarely answer survey questions in perfectly structured language. The agent needs to understand natural responses without inventing facts.
The system therefore preserves raw answers while producing normalized fields.
Interruptions also create complexity.
A respondent may request a callback, refuse a question, end the conversation early, or ask to speak with a human.
The workflow needs to record that state and make a sensible next-step decision.
Webhook handling created another distributed-systems problem.
Webhooks can be duplicated, delayed, malformed, or unauthorized.
The system therefore validates payloads, verifies signatures where configured, deduplicates events, and applies deterministic state transitions.
Another challenge was keeping n8n and Call Aunty responsibilities clear.
n8n is excellent at workflow orchestration and external connectors.
Call Aunty is better suited to phone-specific state, survey behavior, AI-agent planning, and CALL-E semantics.
Keeping those boundaries clear prevented the system from becoming one giant workflow of mixed responsibilities.
Another challenge was building useful visualizations.
A dashboard should not simply look attractive. It should answer operational questions:
What is happening?
Why?
What happened?
What needs attention?
That drove the development of state-oriented visual components instead of decorative graphics.
Testing without production credentials was also important.
Live APIs can be verified through contract behavior and controlled configuration, but that does not mean production credentials or real phone calls were available during development.
The project therefore separates verified code behavior from live deployment claims.
Finally, the project grew rapidly in scope.
It touched AI agents, phone calls, n8n, MCP, CRMs, spreadsheets, Slack, Zapier, surveys, dashboards, and error handling.
The solution was to keep returning to the central product question:
Who are we contacting, why are we contacting them, what did they say, and what should happen next?
That kept the project focused.
Accomplishments that we're proud of
The biggest accomplishment is turning Call Aunty into a complete architecture rather than a simple phone wrapper.
There is now a path from:
natural-language request
to
AI-agent plan
to
policy validation
to
CALL-E execution
to
conversation state
to
structured result
to
external system update.
Another major accomplishment is the integration ecosystem.
The project now contains patterns for CALL-E, MCP, n8n, Google Sheets, Airtable, HubSpot, Slack, and Zapier.
That makes Call Aunty usable as a bridge between phone conversations and existing business systems.
The survey layer is another strong accomplishment.
Surveys can have:
questions
branches
follow-ups
refusals
callbacks
partial completion
structured outputs.
The fallback engine is also a major accomplishment because it treats failures as state transitions instead of generic errors.
The extensive synthetic data enables testing across many realistic conditions without placing real calls.
The visual interface turns complex backend state into information that operators can understand quickly.
The project also establishes a reusable architecture for AI-agent integrations:
interpret → plan → validate → authorize → execute → observe → recover → summarize
That pattern can apply beyond phone calling.
The project has also stayed focused on explicit external side effects, making it easier to reason about when the AI agent is preparing an action versus actually executing one.
What we learned
The first major lesson is that phone automation is a distributed-systems problem as much as it is an AI problem.
The agent, provider, workflow engine, survey, and CRM can all have different states.
The architecture must make those states explicit.
The second lesson is that idempotency is critical when a workflow controls real-world side effects.
A retry is not automatically safe.
The system must know what happened before deciding what to do next.
The third lesson is that AI agents benefit from clear boundaries.
The agent is more reliable when its tools, permissions, policies, and outputs are explicit.
The fourth lesson is that conversation state should be first-class.
A transcript alone does not tell the system which survey question is active, what branch is selected, or what still needs to happen.
The fifth lesson is that raw conversation and structured data serve different purposes.
The raw response preserves meaning and nuance.
The normalized answer enables automation.
Both are valuable.
The sixth lesson is that mock data is useful for product design as well as testing.
Synthetic scenarios reveal missing states, weak UI concepts, confusing errors, and workflow assumptions before real deployment.
The seventh lesson is that n8n and AI agents complement each other.
n8n is strong at orchestration and integrations.
The AI agent is strong at interpreting intent and handling flexible conversation behavior.
CALL-E provides the communication layer.
The eighth lesson is that human handoff should be designed from the beginning.
A mature AI workflow needs an easy path from agent to operator.
The ninth lesson is that observability is part of user trust.
Operators should be able to see:
who was contacted
what state the call is in
what the agent did
what the person said
what happens next.
The tenth lesson is that a simple user experience can sit on top of a sophisticated architecture.
The user only needs to say:
“What do you want Call Aunty to automate?”
The complexity can remain underneath the surface while still being visible when the user needs it.
What's next for Call Aunty
The next step is turning the architecture into a polished end-to-end product experience.
A visual workflow builder would allow users to see:
Contact Source
↓
Policy Check
↓
CALL-E
↓
Survey
↓
Branch
↓
Save Results
↓
Notify Team
Users could inspect and approve that workflow before activation.
Another priority is AI-agent evaluation.
Call Aunty can build benchmarks for intent interpretation, tool selection, survey branching, answer classification, policy adherence, escalation accuracy, and recovery decisions.
Multilingual calling is another major opportunity.
Survey definitions already separate stable question IDs from wording, making localization possible without changing the underlying workflow.
The product can also expand its operator controls so people can pause campaigns, cancel eligible calls, review conversations, retry safe actions, and take over cases that require human intervention.
Analytics can become richer too.
Useful metrics include answer rate, survey completion, average duration, callback rate, escalation rate, question drop-off, failure rate, and retry rate.
A future system could use those metrics to suggest improvements.
For example:
“Question 4 has an unusually high skip rate.”
Or:
“Many respondents request callbacks after the final question.”
That creates the possibility of a closed-loop optimization system.
Another priority is deeper n8n support, potentially including dedicated Call Aunty nodes for common operations such as:
Start Call
Resume Call
Survey
Get Result
Escalate.
A Dify integration could provide another AI-agent interface while Call Aunty handles phone execution and workflow state.
The template library can also expand into reusable workflows for surveys, guardians, appointments, customer feedback, callbacks, research, and support.
Longer term, the vision is to make Call Aunty the conversational front door to automation.
A user should be able to say:
“Call these people and ask this question.”
Call Aunty should transform that intention into:
a plan
a policy check
a safe CALL-E operation
a conversation
a structured result
and the appropriate follow-up.
The system should remain observable, recoverable, configurable, and human-controlled.
That is the central vision for Call Aunty:
Turn human intent into useful real-world conversations, while keeping the workflow understandable, safe, and operationally reliable.
Log in or sign up for Devpost to join the conversation.