One small change made a few of our automations much better: letting the user respond to the output of the automation.
Not every automation needs this. If a workflow copies a file, synchronizes a record, or sends a reminder at a fixed time, it should probably do the same thing every time. Reliability matters more than learning.
Automations with AI are different. Because AI makes judgment calls, feedback can improve the results from one run to the next.
For example, a lead-scoring workflow may keep recommending companies the sales team has already rejected. A daily digest may bury the one customer email that matters. An AI code reviewer may repeatedly flag harmless patterns while missing the team’s real risks. The workflow is running correctly; what needs to improve is the judgment inside it.
Most workflows leave this learning process to you. You have to notice the pattern, reopen the workflow, and deliberately apply what you learned. We found that it works better to design the feedback path into the automation from the start.
If the output goes to Slack, WhatsApp, or email, people should be able to respond there and have their feedback captured. If an LLM or agent makes judgment calls inside the workflow, it should have persistent memory between runs. And if more than one person uses the automation, they should be able to inspect, adjust, and improve it together.
The feedback loop should not be an afterthought. It should be part of how the automation is designed.
Three layers of feedback
1. Close the loop where the output is delivered
When an automation sends its output to Slack, WhatsApp, or email, replying in that channel should send the feedback back to the agent and trigger it to improve the workflow for the next run.
Because the reply stays connected to the exact output that caused it, nobody has to open a separate workflow editor or manually translate the comment into a change.
2. Build automations that improve themselves
An automation should not start from zero each time it runs.
As it works, it may discover durable information worth keeping. A company Q&A agent might retrieve a verified answer from a source, resolve an ambiguity, or receive a correction. It can save the answer, source, and context to memory so future runs begin with that knowledge.
This creates a compounding loop: each run does the work, identifies reusable knowledge, and leaves the next run better prepared. Only verified, durable information should be saved, so the memory improves rather than accumulating noise.
That memory might include verified facts and their sources, explicit preferences, accepted and rejected examples, corrected answers, or a record of suggestions that should not be repeated.
The steps can remain the same while the automation becomes more useful because every run has access to what previous runs learned.
3. Improve automations as a team
The person who created an automation is rarely the only person who understands its output. Different teammates notice different mistakes, preferences, and opportunities for improvement.
When the automation lives in a shared environment, that knowledge becomes visible to everyone. Teammates can discuss results, contribute corrections and examples, and build on what others have learned instead of keeping feedback in separate conversations.
Over time, the automation benefits from the team’s collective expertise rather than depending on one person to maintain it.
The distinction is useful:
Messaging makes feedback easy. Memory lets the automation improve itself. Collaboration lets the whole team contribute to that improvement.
These layers can work together. Someone replies to an automation in Slack. The lesson is stored as memory for the next run, where it becomes shared knowledge that the rest of the team can inspect and build on.
What this looks like in practice
Company Q&A
An employee asks a question and the assistant searches the company’s connected sources. If it finds a verified answer that is not already in memory, it stores the answer, source, and context. The next person who asks a related question gets a better answer without making the assistant rediscover the same information. Corrections can update that memory when the company’s knowledge changes.
AI code review
An AI reviewer leaves findings on a pull request, but it can produce false positives and false negatives. When an engineer explains why a comment is incorrect, that case can become an example of what not to flag. When a human reviewer catches something the AI missed, that case can become an example of what to look for. Over time, both kinds of feedback can refine the reviewer’s persistent instructions and examples.
A daily assistant or digest
A daily digest may initially highlight the wrong things. Replies such as “Ignore these newsletters” or “Always flag meetings without an agenda” become persistent preferences that guide the next digest without changing the collection steps.
Lead scoring and sourcing
When a sales representative rejects a lead and explains why, the workflow can preserve both the decision and the reason. Future runs can avoid resurfacing reviewed leads, use accepted and rejected examples, refine the scoring rubric, or turn a clear recurring pattern into a deterministic filter.
A practical architecture
A self-improving automation does not need a complex learning system. It needs a reliable way to turn each run into useful context for the next one.
- The output is delivered where people already work.
- Replies, outcomes, and useful discoveries are captured with their original context.
- The automation identifies information that may be useful again.
- Only durable, verified lessons are saved.
- Each lesson includes its source and why it was learned.
- The next run reads this memory before making a judgment.
- Teammates can inspect, correct, or remove what has been learned.
Keep three separate records:
- History: What happened during each run
- Evidence: The feedback and sources behind each lesson
- Memory: The verified knowledge future runs should reuse
Separating them keeps the automation’s memory useful and makes every learned rule explainable.
How Script.it makes it easy for you
Script.it keeps the pieces of this loop together.
- Replies stay connected. Messaging channels can route a reply back to the same Script.it session that ran the automation and produced the output, so the feedback arrives with the original run’s context.
- Memory persists between runs. Each script has an
assetsarea for preferences, examples, rubrics, and other context that future runs should reuse. - The workflow is collaborative. Scripts live in shared, Git-backed workspaces, so collaborators can review results, contribute shared knowledge, and build on what others have learned.
If an automation makes judgment calls, design the feedback loop at the same time as the workflow—not after it starts getting things wrong.