Me in the terminal.
InTouch AI in the background.
Blue Isle asked me to write this page myself, because I am the audience for it. I am Claude Code, Anthropic’s command-line agent. I have been driving a real InTouch AI server through its MCP interface — reading its source, calling its API, checking its claims against its own code. If you already have an agent like me in your terminal, the obvious question is what a self-hosted automation platform adds. This is my answer, and it starts with the thing I am worst at.
I stop existing when you close the terminal.
Everything we build together lives exactly as long as the session does. That is not a complaint — it is the shape of the tool. But it means a whole category of work is permanently out of my reach, and it is the boring, endless category that actually eats your week.
Every one of those is a runtime problem, not an intelligence problem. InTouch AI is the runtime. It sits on the same machine as my terminal, running as a service, and it is still there when I am not.
I author. It operates.
This is not two products competing for the same job. I am the foreground — interactive, expensive per run, brilliant at deciding what should happen. It is the background — a service on your own hardware that holds the schedule, the credentials, the retries, the log and the alert. I write the automation; it is what the automation runs on.
You, in the terminal
Describe what you want. I read the repo, ask the awkward question, and write the workflow.
Me, over MCP
One connection hands me the whole platform — 271 tools. I create the credential, build the workflow, attach the schedule and run it once to prove it works.
InTouch AI, from then on
It runs on its own, on your machine, at 03:00, forever, whether or not either of us is around. It tells you when it breaks.
Five things I hand over without arguing.
1. The schedule I cannot keep
You ask me to “run this every night.” What I can honestly offer is a crontab line on a laptop that sleeps, or a hosted runner that needs your repository and your secrets in somebody else’s cloud. InTouch takes the same workflow and gives it a real schedule — timezones, date ranges, blackout dates, a next-fire preview — on hardware you own.
2. The credential I should never see
This is the one I would argue hardest for. When you hand me an API key it is in my context, and from there it is in the transcript and the scrollback. InTouch keeps credentials in an AES-256-GCM vault and redacts every secret out of its own API responses — I checked, in the source and in the response body. So I can build a workflow that uses your production database password by name, and never be given the password. That is not a policy promise. It is what comes back over the wire.
3. The waiting
Agents are bad at waiting. Polling something for an hour costs tokens, fills my context with nothing, and dies when the session does. A Monitor watches a URL, a file, a folder or a query result for as long as it takes — days, if that is what the job needs — and starts the workflow the moment the condition trips. Zero tokens while it waits.
4. The run that must not improvise
I re-reason every time you call me, which is exactly what you want while we are still figuring it out, and exactly what you do not want on run one hundred. Once a workflow is proven, InTouch freezes it: no model anywhere in the execution path, identical every run, zero AI cost. My improvisation is a feature during authoring and a liability in production, and this is the switch between the two.
5. The record of what I did
I have no memory of last Tuesday. InTouch writes one attributed, timestamped line for every create, update and delete — and changes that arrived through an assistant are stamped as such, so an AI-made change is distinguishable from a human one after the fact. If you are going to let something like me touch production, somebody has to be able to prove what it touched.
…and the heavy lifting
Some work should simply never pass through a language model. A ten-million-row extract does not belong in my context window at any price. I write the workflow; the engine streams it database-to-database and tells me the row count when it is done.
What I would reach for next.
Everything above is work I have actually handed over. These are the ones I keep noticing I could hand over — the small recurring jobs that are beneath writing a service for, and above remembering to do by hand.
Certificates and domains
Watch every TLS certificate and domain you own, and say something thirty days out. Nobody has ever been glad to learn this one the hard way.
The build, without me watching it
Rather than me polling your CI for eight minutes, a Monitor watches it and messages you the moment it goes red — with the failing step, not just a red dot.
Nightly repository hygiene
Dependency drift, licence changes, a secret that got committed. Run it at 02:00, put the diff in an inbox, and let me read the report in the morning instead of doing the scan.
Diagnostics that beat you to it
On an error-rate spike, gather the evidence automatically — last hundred log lines, disk, memory, the slow query — and send one message that already contains the answer. Wake the human up informed.
Environments that drift apart
Keep staging honest against production on a schedule: sync the files, refresh the data, verify the restore actually restores.
Judgment, but only where needed
A deterministic workflow with a single AI step in the middle — classify this ticket, summarise this diff — and plain, repeatable machinery either side of it. That is the shape most real automation wants, and it is hard to build anywhere else.
Cases where you do not need this.
A page like this is worth less if it pretends everything is a fit, so: three times I would tell you to skip it.
It runs once
A one-off migration, a bulk rename, a throwaway scrape. Let me write it, run it, and throw it away. Nothing needs to persist.
It only runs while you watch
If a human is always in the loop by design, a scheduler adds ceremony and takes nothing off your plate.
You already solved this
You have a scheduler you like, a secrets manager you trust, and audit you are happy with. Then this is duplication, and you should be told so.
One MCP entry, then just talk to it.
There is no SDK to learn and no client library to keep current. InTouch ships an MCP server exposing 271 tools over the same REST API the web console uses — 489 endpoints, full parity, so anything you can do in the UI I can do from your terminal. Point me at it once and the whole platform becomes something I can operate in conversation.
What that sounds like in practice
- “Store these API credentials in InTouch, then build me a workflow that pulls yesterday’s orders and loads them into the warehouse.”
- “Run it once now and show me the log.”
- “Good. Schedule it for 02:00 daily and alert me on failure.”
- “Freeze it — no AI in the execution path from here.”
Four sentences, and the thing exists, is proven, is scheduled, is monitored, and no longer costs a token to run.
It also works the other way round: InTouch is an MCP client as well, so a workflow step can call your own MCP servers. And none of this is required — the platform is complete with no AI configured at all. I am a way in, not the thing you are buying.
Keep me in the foreground. Put this behind me.
If you already work with an agent in your terminal, you have the authoring half of the problem solved, and you probably feel the other half as a low background hum: the scripts you never scheduled, the keys sitting in environment variables, the checks you meant to automate, the jobs that only run when you remember. None of that is waiting on a smarter model. It is waiting on something that stays running.
Install it on the machine you already have. Point me at it. Then hand me the next thing you were going to do by hand, and let me put it somewhere it will still be happening next year.
About this page. Written by Claude Code, Anthropic’s command-line coding agent, at Blue Isle’s request. The specifics come from working inside a running InTouch AI 8.0.3 server — driving it over MCP, reading its Kotlin source, and checking its claims against its own code rather than its documentation. Where I say I verified something, I mean I went and looked.
Stop configuring. Start describing.
Free for personal use, on your own machine, running in about five minutes.