Self-learning founder support loop

Built from the system Amos Bar-Joseph, CEO at Swan AI, described on GTM Vault GTM 16 (https://pro.gtmvault.co/episodes/gtm-16). Published free by GTM Vault. Amos gave no result numbers for this system on the record; your results will differ.

When to use this

Use this when a small founding team is answering a growing volume of repeated requests, such as customer support, and the default answer would be to hire more people for the queue. Amos frames the old playbook as throwing more bodies at scaling problems: more support tickets meant more support agents, more pipeline meant more SDRs (GTM 16, 14:10 and 15:14). His team set out to scale as three founders with no additional hires, which he calls the biggest challenge in the company (GTM 16, 8:55). The loop fits teams that already work in Slack and can put an agent in the path between the customer and the people who know the answers. The support loop is his worked example; he applies the same method to every scaling process (GTM 16, 9:41).

The system on the record

Amos describes one rule for every scaling process at Swan: do it completely manually first with all the founders involved, find the way of doing it that repeats and works, document it, and only then teach an AI agent to do at least 80% of it, "not 100%" (GTM 16, 9:41). Customer support is the example he gives, and it runs in four stages:

1. Founders answer everything. At the start the founders took every customer support request themselves (the transcript places this on Slack) and documented the resolutions (GTM 16, 9:41).
2. Agent in the middle. The team then added an AI agent between the user and the founders. At this stage the agent relays the support request to the founders, takes their resolution, rewrites it more clearly, and documents it in a knowledge base (GTM 16, 9:41).
3. Answer or escalate. Over time the knowledge base holds every resolution written to customers. The agent now takes each request, checks the knowledge base, and responds immediately if it has the answer. If it does not, it escalates to the founders (GTM 16, 10:45).
4. Close the loop. On an escalation the founders write the resolution to the agent, the agent passes it to the user, and the resolution is stored in the knowledge base so the agent can resolve that query the next time. Amos calls the result a self-learning support system: every time the founders give input, the system learns (GTM 16, 10:45).

Two design choices sit around the loop. First, the interface is Slack. Swan's own agent runs as a Slack app, and research, configuration changes, support questions and how-to questions are all a message to the agent (GTM 16, 16:17 and 17:05). He says this makes feedback loops fast because changing something is a message away (GTM 16, 17:05). Second, he holds automation to one test: use AI to remove complexity, not to add it for the sake of automation, with the aim of fewer system interactions and more human interactions (GTM 16, 16:17). He puts sellers at around 60% of their time working in systems across 13 different tools as the problem this test addresses (GTM 16, 2:07).

The result

1. Amos gave no numbers for the support loop: no resolution rate, response time, ticket volume or founder hours saved.
2. The 80% figure is his target for how much of any documented process an agent should take on, not a measured resolution rate (GTM 16, 9:41).
3. The operating goal he stated is three founders getting to $30 million ARR with no additional hires (GTM 16, 8:55). He did not say where the company stands against it.
4. For changes made through the Slack agent in his own product, he says a task that would take 30 minutes becomes a 10 second message (GTM 16, 17:05). That is a product claim, not a measured result of the support loop.

Run it on your company

1. Ask once, in one message, for: the process to run through the loop (support first, unless another queue is heavier); where requests arrive today (Slack channels, shared inbox, chat widget); who answers them now and how many people that is; rough weekly volume; where past answers live, if anywhere; the agent or LLM platform available; whether the team can add a Slack app; and who on the founding team owns escalations.
2. Run the manual phase on purpose. Every request goes to a founder, and every answer is logged as a resolution. Output: a resolution log template with columns Date, Request (verbatim), Category, Resolution (as sent), Answered by, Reusable (yes or no), plus a rule for how long the manual phase lasts before step 3 starts. Amos gave no duration; set one with the user.
3. Define what "repeatable" means for this process. Output: a short checklist the founders sign off before any agent goes in, covering the request categories that recur, the resolutions that are reused, and the categories that must always stay with a human. Use Amos's target of at least 80%, not 100%, as the scope line (GTM 16, 9:41).
4. Build the knowledge base from the log. Output: a knowledge base schema with columns Entry ID, Question pattern, Resolution, Source request, Written by, Last updated, plus the first set of entries converted from the reusable rows in the log.
5. Insert the agent in relay mode. The agent sits between the user and the founders, forwards each request, takes the founder's answer, rewrites it clearly, sends it, and files it in the knowledge base. Output: a fenced agent prompt for relay mode, and a Slack routing spec with columns Source channel, Agent action, Founder channel, Knowledge base write.
6. Switch the agent to answer or escalate. Output: a fenced agent prompt that takes one request, searches the knowledge base, answers only when it finds a matching resolution, and otherwise escalates to the named founder channel with the request and what it searched; plus the escalation message format and the rule that every founder reply to an escalation is written back to the knowledge base as a new entry.
7. Apply the complexity test before adding anything else to the agent. Output: a table with columns Proposed automation, System interactions removed, System interactions added, Human interactions affected, Keep (yes or no). Drop anything that adds steps for the team or the customer (GTM 16, 16:17).
8. Repeat the method on the next scaling process. Output: a ranked list of the team's other repeated processes with columns Process, Current owner, Weekly volume, Manual phase status, Agent stage (none, relay, answer or escalate).
9. Set the scorecard, since Amos gave none: share of requests answered from the knowledge base without escalation, escalations per week, time from escalation to founder answer, new knowledge base entries per week, and founder hours on support, reviewed weekly.

Tools on the record

1. Slack: interface the agent runs through.

Any tool doing the same job works; the method is the point. Full stack by layer: https://pro.gtmvault.co/stack/operator/amos-bar-joseph

Where it breaks

1. Skipping the manual phase. Amos starts every process by hand with all the founders involved and only automates once the team knows how to do it in a way that repeats and works (GTM 16, 9:41). An agent trained before that point has nothing reliable to learn from.
2. Aiming for 100%. His target is that the agent does at least 80% of a process, not all of it (GTM 16, 9:41). The loop depends on the agent escalating what it cannot answer rather than guessing.
3. Escalations that never come back. The system learns only when the founders write the resolution to the agent and it is stored for next time (GTM 16, 10:45). If escalations go unanswered or are answered outside the loop, the knowledge base stops growing.
4. Automation for its own sake. He uses AI to remove complexity, not to increase it just for the sake of automation (GTM 16, 16:17). An agent that adds tools, steps or system work for the team repeats the problem of sellers spending around 60% of their time in systems across 13 tools (GTM 16, 2:07).
5. Removing the human from the relationship. He says agents should take the tedious system work but never replace the human interaction (GTM 16, 13:21). In this loop the founders stay as the escalation path and the source of every new answer.
6. No measurement. Amos gave no figures for the loop, so a team running it has no benchmark to compare against and needs its own scorecard from step 9.