Canonical page: https://tellenze.com/blog/run-your-first-loop # Run Your First Loop ![Two people follow a teal feedback loop connecting a customer message, focused work, implementation, evidence and a notebook of lessons.](https://tellenze.com/blog/run-your-first-loop/cover/01m46pv27hp34m6s4ba509zp53) Follow one customer problem from feedback to a verified change, a useful lesson and a better next decision. A practical guide to the six practices of the Loop. A customer reports a problem. Someone investigates, a change ships, and the ticket closes. A few weeks later, another team makes a similar mistake. The missing connection is often the lesson: what the team discovered, why it chose that response, and what should change in future work. In [The Loop: A Human Practice for the Agentic Era](https://tellenze.com/blog/the-loop-a-human-practice-for-the-agentic-era), we introduced six connected practices: **Focus, Execute, Observe, Review, Learn and Adapt**. Here is a way to try them with one piece of work you already have. Start with a problem small enough to investigate and check. Give it an owner, keep the evidence nearby, and follow it through to the next decision. ## Start with one customer problem Imagine a team building an order-management product. A customer tells support: > “I filter orders to last month, but the CSV download includes orders from the whole year. I have to clean the file before I can use it.” Support reproduces the mismatch and records the steps, selected dates, expected result and actual result using a safe test account. This is a fictional example. The defect, team and outcomes below illustrate the practice; they are not a customer case study or measured Tellenze results. The report gives the team a concrete question: how can customers download a report that matches the selection they made? ## Focus: agree on the outcome Before deciding how to fix the export, the team writes down what success means: **Customers can export the orders selected by their date and status filters, within the records they are allowed to access.** That sentence gives the investigation direction. It also exposes details the original report left open. Do status filters affect the export? What happens when no orders match? Does the export enforce the same access rules as the screen? The team agrees on observable acceptance criteria: - The export includes all matching orders across the selected period, including results beyond the current screen page. - It respects the selected status and the customer's existing access permissions. - An empty selection produces a clear, useful response. - Regression checks cover date boundaries, combined filters and access permissions. One person owns the outcome. An engineer owns the implementation, with support helping to check the original customer journey. The scope stays with export correctness; redesigning the reporting interface would need its own reason and decision. The team also agrees how it will check the result after release: repeat the reported journey and inspect the next normal reporting cycle. ## Execute: investigate, decide and deliver The engineer follows the report through the product. In our example, the screen and export use different selection logic. The export receives the date filter but does not apply it. The team records the finding and its decision: make both paths use the same filtering rules, while preserving the export's access checks. A connected coding agent could help inspect the relevant code, prepare a patch and add regression tests. Its brief includes the customer problem, agreed criteria, relevant code and constraints. The engineer reviews the proposed change and verifies the result before the authorized release. As the work progresses, the work item gains the evidence someone else would need to understand it: the reproduced failure, the implementation, test results and the release reference. If a dependency prevents release, the owner records what is needed and who can resolve it. A useful progress update makes the next decision clear. ## Observe: check what changed for the customer After release, support repeats the original journey with a safe test dataset. The screen and downloaded report now agree for the selected period and status. The team checks the boundary cases too. A successful test run helps establish that the implementation behaves as intended. Repeating the customer journey checks whether the delivered change addresses the reported problem. Observation continues through the next reporting cycle. Does the mismatch recur? Are customers still manually cleaning exports? Has the change introduced a different failure? Keep the limits of the evidence visible. A quiet support queue alone cannot establish that the problem has disappeared. Customers may have stopped reporting it or found a workaround. Record what was checked, what happened and what still needs observation. ## Review: compare the result with the intent The owner brings the evidence back to the original outcome. In this example, the reproduced journey and regression checks support closing the export defect. Any remaining uncertainty about broader usage stays explicit. A short review can answer three useful questions: 1. Did the delivered change meet the agreed criteria? 2. What did the investigation reveal about the way we work? 3. What needs to happen next, if anything? The discussion reveals a process gap: previous tests checked the screen and export separately, so their disagreement went unnoticed. That finding explains how a small defect escaped. It gives the team a specific improvement to consider. ## Learn: keep a lesson someone can use The team saves a short decision note alongside the work: **When a feature shows a filtered selection and offers an export, verify that both apply the same selection and access rules. Check pagination and empty results explicitly.** The note links to the original problem, the change and the verification evidence. It records why the team chose shared filtering logic and when the guidance applies. This is enough to help the next person. An engineer implementing a new download can use the check. A reviewer can ask for the evidence. An agent working on a related feature can receive the note as part of its context. Give the lesson a canonical home and an owner who can revise it as the product changes. Linking to that home helps the guidance travel without creating competing copies. ## Adapt: let the lesson shape the next work The team adds a screen-and-export comparison to its review checklist. Future briefs for reporting features include the same boundary checks. It also considers whether other exports need investigation. That becomes follow-up work only if there is a distinct outcome worth pursuing; the original defect can remain complete with its evidence intact. The next Loop begins with better context: a known failure pattern, a reusable check and a clearer question. You can return to any practice as evidence changes. A new observation may change the scope during execution. A review may reveal that the original success measure was inadequate. The six practices stay useful throughout the work. ## Give the Loop a home in Tellenze Tellenze helps keep the problem, decisions, delivery evidence and learning connected. Use a [work item](https://tellenze.com/help/work-items) for the outcome, acceptance criteria, ownership and progress. Add the decisions and verification evidence as the work develops, then record what was delivered when it is complete. Where your workspace has [Signals](https://tellenze.com/help/signals), you can retain customer reports as evidence and connect them to reviewed resolution work. Looper can help organize reports and suggest work; members review those suggestions and confirm resolution. Keep the reusable lesson in [Knowledge](https://tellenze.com/help/knowledge), linked to the work it explains. For [connected agents](https://tellenze.com/help/agents), include that guidance with the intended outcome, constraints and acceptance criteria. Available capabilities depend on workspace settings, permissions, plan and provider setup. The shared record should make the next contributor's job easier: what happened, what was decided, what was checked and what to carry forward. ## A template for your first Loop Copy these prompts into the place where your team keeps its work: - **Problem and evidence:** What happened, to whom, and where can we inspect it? - **Intended outcome:** What should become possible or better? - **Owner and boundaries:** Who is responsible, and what is outside this effort? - **Acceptance criteria:** Which observable checks will establish that the change works? - **Delivery decision:** What did we choose to change, and why? - **Observation:** When will we check the result, using which evidence? - **Review and learning:** What did the result teach us, and where is the lesson saved? - **Adaptation:** What should change in the next brief, checklist or priority? For your first attempt, choose one existing customer problem. Agree on the outcome and the observation before work begins. After delivery, bring the evidence back to the team and save one lesson that can improve the next piece of work. That gives your first Loop somewhere concrete to start—and somewhere useful to go. ## Further reading - [The Loop: A Human Practice for the Agentic Era](https://tellenze.com/blog/the-loop-a-human-practice-for-the-agentic-era) — the introduction to the six practices. - [The Tellenze Loop](https://tellenze.com/the-loop) — explore the practices and how they connect. - [Create and complete useful work items](https://tellenze.com/help/work-items) — define outcomes and keep delivery evidence with the work. - [Turn Signals into reviewed work](https://tellenze.com/help/signals) — connect customer reports to considered action. - [Write, discuss, and organize knowledge](https://tellenze.com/help/knowledge) — retain decisions and lessons for future work.