Looptah Connect · Single Responder example

Benjamin Franklin Single Responder

Email in, one voice out. A subscriber sends a question to a dedicated address; minutes later they get a considered reply from Benjamin Franklin — printer, scientist, diplomat, and the most quotable pragmatist of the eighteenth century. No committee, no hand-off, no one sitting at an inbox making it happen.

It is the same Looptah Connect responder that powers the Gnews Gnugget Team Responder, with one persona behind it instead of a panel. That's the point: the plumbing doesn't change when the org chart does. One expert or a whole roster, same stack.

Confidence is provisional. Verification is mandatory.

Email-driven Serverless Single persona Scales to zero Your cloud or ours

What it does

One channel in, one channel out — email. Everything in between is handled for you.

01

Reads the mailbox

Every message that lands at Franklin's address is picked up automatically the moment it arrives — parsed, decoded, and cleaned into plain text ready to work with.

Auto-triggered Any client
02

Decides what to do

It checks who sent it, how long it is, and whether it's safe to act on — then routes accordingly. Valid questions go to the persona; everything else gets a helpful, on-brand response or is quietly ignored.

Sender rules Safety checks
03

Answers in one voice

Franklin gives a single, direct answer — no labelled turns, no debate to read through — and the responder emails it back with the original message quoted below, exactly like a real reply.

Persona voice One answer
Portrait of Benjamin Franklin by Joseph Duplessis

Benjamin Franklin

Printer, postmaster, scientist, diplomat — and a man who spent his life explaining complicated things to people who hadn't the time for them. Plain-spoken, wry, allergic to dogma, and constitutionally incapable of a long answer when a short one will do. He is the pragmatist: less interested in what we ought to feel than in what is to be done.

Hear him first

Reading about a persona is one thing. Listening to one hold up its end of a conversation is another. Franklin sat for a full interview on Talking to the Machine — the same persona this responder writes with, in audio.

Listen to the interview Free to read and listen · Talking to the Machine on Substack

Franklin is a show persona from Talking to the Machine, but the responder behind him is the business article. Point it at any persona you like — the one your customers should hear from, in the voice your organization actually uses.

Single or team

One expert, or a room full of them.

Looptah Connect responders come in two shapes, and the difference is not technical — it's editorial. A single responder gives an answer. A team responder gives you the argument that produced it. Pick by what the reader needs.

  Single Responder Team Responder
Example Benjamin Franklin (this page) Gnorm & Seamus
The reply One unlabelled answer, signed by the persona. Labelled turns — each persona reacts and answers in sequence.
Best for Expert desks, FAQ and support lines, intake, anywhere a clear answer beats a discussion. Second opinions, red-teaming, editorial and entertainment, anywhere disagreement is the value.
Cost & latency One model call per message — the cheaper, faster of the two. One call per persona per round; richer output, proportionally more of both.
Under the hood Identical. Same parsing, same allowlist, same anti-spoof and loop guards, same rate limits, same packaging — a single deployment variable decides which one you get.

They run side by side quite happily. Each responder gets its own mailbox, its own rate allowance, and its own failure log, so a busy support line never eats into the expert desk's budget — or its reputation.

Under the hood

How it works

The whole thing is event-driven and serverless. Nothing runs until an email arrives. This example is built on AWS — the pattern maps cleanly onto any major cloud.

Event flow An email arrives at SES, is stored in S3 under the Franklin prefix, which triggers a Lambda function that runs the single-persona engine and sends the reply back through SES. Inbound email one question Amazon SES receives mail S3 bucket own prefix, triggers Lambda one persona + guardrails Amazon SES sends reply Reply signed by Franklin
1

Mail arrives at SES

Amazon SES receives email for Franklin's address and writes the raw message straight to its own prefix in the S3 bucket. No inbox to poll, no mail server to run.

2

S3 triggers the function

The new object fires an S3 event that invokes this responder's own Lambda function — routed by prefix, so the team responder never sees the message. Compute spins up on demand, only for this email.

3

The function reads & screens

Lambda parses the MIME email, extracts clean text, and runs the guardrails — sender allowlist, length limits, attachment and anti-spoof checks, and per-sender throttling backed by its own DynamoDB table.

4

Franklin responds

Cleared messages become a task the persona engine runs with a single speaker — no panel, no hand-off, and a tighter length guardrail than the team version — using the model of your choice, with the API key held in a managed secrets store, never in code.

5

The reply goes out

The responder composes the answer in Franklin's voice, signs it, quotes the original message below it, and sends it back through SES to the original sender.

6

It goes back to sleep

When the message is handled, the function exits. Nothing is left running and nothing is billed until the next email lands.

Separate by design

Franklin shares the storage bucket, the model credential, and the dependency layer with the team responder — and nothing else. His function, permissions, logs, dead-letter queue, and rate-limit table are all his own. One responder getting hammered can't slow, silence, or bill the other, and when something fails you know immediately which desk it failed on.

Persona-agnostic

Franklin is the default, not the design.

The single responder doesn't know or care who is answering. The persona is a deployment setting — point it at a different one and redeploy, and the same mailbox now answers as someone else entirely. Nothing in the parsing, screening, or sending changes.

Swap the voice

Any persona in the library, standard or custom. Franklin today, your head of support tomorrow, without touching a line of the plumbing.

Run several at once

Each additional responder is a new address, a new prefix, and a new function. Different personas, different mailboxes, independent budgets and logs.

Or promote to a team

Decide the question deserves an argument rather than an answer? The team responder is the same stack with more than one speaker configured.

Where it runs

Hosted by Looptah, or built on your infrastructure.

The responder is a small, portable stack of managed services. That means you can hand it to us entirely — or run the exact same design inside your own cloud account, under your own controls.

Hosted by us

We stand it up in Looptah's cloud and operate it. You point a mailbox at it and start getting replies. The fastest way to a working responder, with nothing for you to maintain.

Fastest setup Fully managed

Built on yours

Deployed into your own AWS account from infrastructure-as-code — SES, S3, Lambda, DynamoDB, and Secrets Manager — inside your VPC, under your IAM, against your data-residency and governance policies.

Your cloud Your controls IaC deploy
Model-agnostic

Like the rest of Looptah Connect, the persona engine runs on the AI platform you prefer — Gemini, Claude, or OpenAI — or a local model when the work can't leave the building. Swap the model without touching the plumbing.

Built-in guardrails

It knows what not to answer.

An open mailbox is an open door. The single responder ships with exactly the same checks as the team version — the guardrails are part of the platform, not the persona.

Sender rules

A defined list decides who gets a persona reply. Everyone else gets a friendly pointer to subscribe — at most once an hour.

Length & format

Messages that are too long, too short, or carry attachments get a clear note asking the sender to adjust and resend.

Anti-spoof

Spam, malware, and failed-authentication mail is dropped before the persona ever sees it — no backscatter, no reputation hit.

Its own throttle

Per-sender rate limits and loop detection, tracked in this responder's own table — so Franklin's allowance is independent of every other desk you run.

Secrets kept secret

Model API keys live in a managed secrets store with least-privilege access — never in the code or the config.

Failure handling

Anything that errors out lands in this responder's own dead-letter queue for review instead of vanishing — attributable to the right desk, and nothing silently lost.

Free consultation

Want one of these on your own mailbox?

The Benjamin Franklin Single Responder is one example of Looptah Connect. Tell us what channel you'd want a persona behind — support, sales, intake, an expert desk, or something stranger — and we'll show you what it would take. One voice or a whole panel. Hosted by us, or built on your cloud.

Book a free consultation See the Team Responder Explore Looptah Connect