Agentic AI, Self-Hosted

Stop configuring. Start describing.
Your automation platform answers in plain language,
on the AI provider you choose.

The old paradigm is out. The new paradigm is AI. AI automation is InTouch AI. This assistant isn't a feature bolted onto a config-era console — it's the front door to a platform built with AI at its center. The vault, the connectors, the scheduler, RBAC, the audit log: all of it sits behind the assistant, and the assistant drives all of it. This is an agent, not a chatbot. Tell it what you need; it creates the jobs, runs the tools, manages the credentials, installs the skills, queries the data, and sets the schedules. Every action runs through tool-use semantics, so every move lands in the audit log with the tool name, inputs, and output — nothing hidden. It works from the web UI and from every configured messaging channel, carrying one conversation across every surface.

For thirty years, the automation contract — what to do, when, what to do when it works, when it doesn’t, and who to notify — was powerful but demanded someone who thinks in schedules, triggers, and task graphs. The assistant collapses that barrier: describe what you want in plain language and the contract gets built for you. AI is the accessibility layer — the reason someone who would never touch a job config can now run real automation.

"What Can You Do?"

Ask, and it answers in your context — what it can build for you, right now. Not a feature list. An answer.

InTouch AI assistant answering what it can do

One Assistant. Every Job Function.

Same engine, same tools, same audit trail — sharpened to the person asking. Nineteen real conversations. One product.

Click any thumbnail to enlarge.

Most AI Answers. This One Acts.

An LLM in a chat window summarizes a doc and drafts a paragraph. That's where most "AI" quits — because it was bolted onto a config-era core that has no idea what your automation is doing. You can't bolt on a center. Here's what happens when the AI is the architecture and does the actual work — with the governance enterprise teams demand.

From Q&A to Action

Before: "Hey ChatGPT, what jobs failed last night?" — and a polite reminder that it can't see your data.

After: an agent with 76 tool_use functions calls get_all_work_history, then get_active_job_log for the failures, then drafts the status summary — one turn, your server, your audit log. The old "what to do when it doesn't work" clause was a dumb rule: retry N times, email a log. Now it's an assessment. It reads the failure, knows why, smart-retries, refreshes an expired token, and surfaces the one sentence that matters. "It broke. Here's why. I fixed it." No config-era tool can say that.

From Open Permissions to Bound by RBAC

Before: a "do-anything" agent that logs in as a service account with broad credentials, invisible to your audit trail.

After: the assistant operates as the calling user. RBAC enforced per action. Credential vault never exposed. Every tool call logged with the user identity, inputs, and result. Compliance and security stop saying no.

From Code-Only to Every Surface

Before: the agent hides behind a developer-only API. Business teams file tickets and wait for engineering to translate.

After: the same agent works from the web UI, the InTouch PWA, the InTouch Android app, and the REST API — one multi-turn conversation across every surface, open to anyone with a publisher login.

What the Assistant Actually Does

A

Agentic, not Conversational

Tool-use is the first-class interaction pattern — not an afterthought. The assistant sees a roster of platform tools (create_job, run_task, list_credentials, install_skill, configure_schedule, and more) and invokes them to do what you asked. The answer you get back is the result of real work, not a paragraph about it.

M

Multi-Turn Memory

Chat history persists across sessions. The assistant auto-titles conversations, so "the one where we fixed the payroll export" is actually findable. Context carries forward — follow-ups never start from zero.

C

Surface Passthrough

Start a conversation in the web UI, continue from the InTouch PWA on your phone, finish from the Android app — same chat history, same context. Every surface authenticates with your InTouch AI login.

R

RAG-Grounded Answers

Documents chunked and embedded into any of the 7 supported vector stores. Retrieval-augmented responses cite your documents — the assistant answers from your data, not from training-set hallucinations.

S

Streaming SSE

Server-Sent Events stream the assistant's response as it's generated — tokens arrive as they're produced, straight into the browser. Time-to-first-byte is a solved problem; no waiting on a spinner.

K

Skill Invocation

Type @ followed by a skill name in the assistant chat to run a skill directly, bypassing the agent loop entirely. Deterministic, fast, audit-logged. Great for "just run the weekly thing" shortcuts.

One assistant, on every screen

Same chat history, same audit trail — at your desk or on your phone. Every surface authenticates with your InTouch AI login, and every surface is served from your own server.

🖥

Web console

The full management UI — a fast, modern interface your InTouch AI server hosts itself, same-origin. Nothing to install; open it in any browser and press Ctrl + Enter anywhere to summon the assistant.

📱

Installable PWA

A Progressive Web App for the assistant — open it in any mobile or desktop browser and Add to Home Screen. Installs like a native app, works offline, no app store. Ships with InTouch AI.

The Provider Is a Config Setting, Not a Vendor Lock-In

InTouch AI speaks to eight AI providers natively in every edition: Anthropic Claude, OpenAI, Mistral, Groq, DeepSeek, xAI Grok, Google Gemini, and Ollama (for local models). Hugging Face rounds out the set as a 9th, job-only provider. Each is a first-class tool. The assistant itself and every individual AI tool can target a different provider, swappable per tool by changing the tool name and credential reference.

If Anthropic refuses your domain — and it sometimes does: financial advice, legal synthesis, medical analysis — swap to Ollama with a local model. Zero restrictions, zero API cost, no data leaving the network. Works air-gapped. The job definition doesn't change; only the tool name and credential do.

This isn't an abstraction layer that papers over provider differences. Each provider's distinctive features (Claude's extended thinking, OpenAI's function calling variants, Gemini's multi-modal, Ollama's local model roster) is exposed directly. Swap when the use case changes. Don't accept a lowest-common-denominator wrapper.

# Restricted domain? Local model. - name: classify-complaint tool: ollama credential: ollama-internal model: llama3.2 prompt: "${input}" # Deep reasoning? Claude Opus. - name: summarize-contract tool: anthropic credential: anthropic-prod model: claude-opus-4-6 # Volume pricing? GPT-4o-mini. - name: enrich-row tool: openai credential: openai-prod model: gpt-4o-mini

Conversation Is the Primary UI

This is built for how people work now: describe intent, don't configure. You say what you need — the assistant builds it. Jobs, schedules, credentials, triggers, alerts, skills. The web UI forms are for verification and fine-tuning; the assistant is for creation. And because you didn't write it line-by-line, you can't be left holding a job you can't debug — when something breaks, the assistant reads the failure for you.

Example: "Build me a sales export"

"Every weekday at 6am, export the sales table from the prod MySQL, transform to add YoY deltas, and email the CSV to [email protected] with a one-line summary."

The assistant creates the credential references, the job with four tools (SQL → DataFrame → Anthropic summarize → Email), a weekday schedule at 06:00, and attaches an alert. Walks you through each step for confirmation. End state: a working pipeline and a test run.

Example: "Who's got access to prod-mysql?"

"List all publishers and groups with read or update rights on the prod-mysql credential."

The assistant queries the RBAC tables, filters to that credential's rights matrix, renders a table in chat. You didn't need to remember which endpoint or which filter. You asked the question.

Things That Made the Product Better the Boring Way

System-Prompt Discipline

The assistant's system prompt is tight — tools are described in structured JSON schema, not prose; the reference knowledge base loads via keyword-retrieval RAG, not a full-document dump. That kept the context window honest and the response times sub-second.

429 Retry with Backoff

Rate-limit responses from any provider are retried with exponential backoff and jitter. The assistant doesn't give up on the first 429; it surfaces the issue only when retries are exhausted. Invisible robustness, which is the good kind.

Tool Classification + Caching

Not every message needs the full agent loop. A classifier routes trivial questions to cached responses; heavy orchestration messages go through the full tool-use pipeline. Cost goes down, TTFB goes down, nothing else changes.

The Conversation Stays on Your Server

No Third-Party Middleman

The assistant runs in your InTouch AI server. Messages from Slack go from Slack straight to your server, not to a SaaS relay in between. The data path is one hop shorter than every "AI chatbot" product built on top of OpenAI.

Auditable Reasoning

Every tool call the assistant makes is logged with the arguments it chose. Reviewing "why did it do that?" is a log query. Contrast with closed assistants where the reasoning chain is a black box even to the vendor.

Air-Gapped Option

Run everything on Ollama. No upstream network calls. Great for defense, medical, legal, and financial deployments with strict egress controls.

Talk to Your Automation Platform

The old paradigm is out. The new paradigm is AI. Describe what you need, get a working pipeline that heals itself when it breaks, and run it all on your own server. Try it free with the Personal edition.

Get Personal Edition Talk to Sales