Business-configured conversational agents

TACA — TOOT AI Conversational Agent

Create, teach, test and publish a conversational agent configured around business knowledge, behaviour, requests and human handover.

Active product
TACA website widget: a test visitor asks about Arabic and English support and a demo; the agent identifies itself as TACA and links to a request form.
Published TACA widget capture — test visitor, no client data.

Overview

From business needs to a published agent

  • Input
  • Rule / logic
  • Human
  • Output
  1. 01Input
    Create

    Define a use case

  2. 02Rule / logic
    Teach

    Build a structured playbook

  3. 03Human
    Test

    Test conversations

    ✓ Tested before publishing
  4. 04Output
    Publish

    A website-facing agent

TACA's Create → Teach → Test → Publish workflow. Product material also describes bilingual interaction, human escalation and usage monitoring.

TACA's documented architecture

  1. EdgeCloudflare
  2. Web applicationNext.js
  3. APINode.js / Express
  4. Data & background workMySQLRedis / BullMQ workers
  5. Managed servicesGoogle Dialogflow CXStripe
From the active implementation's documentation. Managed cloud services are part of the architecture; TACA is not an entirely local-model product.
01

From business needs to a published agent

TACA follows a Create → Teach → Test → Publish workflow. Teams define a use case, build a structured playbook, test conversations and publish a website-facing agent. Product material also describes bilingual interaction, human escalation and usage monitoring.

02

Implementation architecture

The documented active implementation uses a Next.js web application, a Node.js/Express API, MySQL, Redis/BullMQ background workers, Google Dialogflow CX and Stripe, with Cloudflare in front. TACA is not an entirely local-model product; managed cloud services are part of its documented architecture.

03

Platform operations

The product documentation covers agent subscriptions and configurable usage limits, quotation requests, manual and Stripe payment paths, subscription management and delivery tracking. Security-related work includes documented session/device management, revocation, MFA and server-side permission controls. Dated project records contain test results, but these are historical engineering records rather than an independent assurance statement.

04

Evidence and limitations

An unnamed UAE bank evaluated bilingual responses about banking products, policies and procedures. That is an evaluation, not a confirmed production deployment. Current management screens and the exact latest release state still require verification. A separate interactive TACA showcase on this website contains authentic published captures and source-derived technical explanations.

Published captures

TACA website widget: a test visitor asks about Arabic and English support and a demo; the agent identifies itself as TACA and links to a request form.
Published TACA widget capture — test visitor, no client data.
TACA enquiry form with empty fields and the TACA demo option already selected.
The associated request form, as published.

Evidence and status

Active product

Inspected active repository and documented product; individual release claims require current verification

A publicly described product.

Source: www.tootholding.com/products/taca

Talk to us about the problem.

Start with the workflow, your constraints and what a successful implementation should achieve.