Goals Give Loops Direction
An agent can research, write, analyze, and act. The useful question is not how much it can do, but which change you want that work to produce.
A goal describes that change. A loop is a repeatable way to do useful work, examine the result, and decide what to do next. Maintained knowledge connects the runs so each one can use what the previous ones learned.
The environment tells an agent what is known and what it can do. The goal tells it what is worth doing next. Feedback tells it whether that was useful.
Start with the change you want
Suppose you want to build an educational channel that people return to, within a production budget you can sustain. Publishing a video is one task. Trying shorter demonstrations is one strategy. Views, audience feedback, returning viewers, and production effort are evidence you might use. None of those is the entire goal.
This distinction matters when choosing work. An agent could make more videos, improve an existing explanation, investigate who the audience is, or remove a production bottleneck. The goal helps it compare those options instead of selecting whichever task is easiest to complete.
You do not need a complete specification before beginning. Start with the outcome in ordinary language. Your agent can use existing work to propose a first interpretation, identify important constraints, and choose a small next step. Clarify the goal as you learn. Keep the desired outcome distinct from the current strategy and measurement.
For the first interaction, How to Start begins with the outcome rather than asking you to design a document structure.
Connect action to feedback
A useful work loop follows this relationship:
Goal -> current understanding -> bounded action -> observed result -> revised understanding -> next action.
Read the current state. Recover the goal, the evidence, the current approach, previous attempts, and the limits on what may happen. What matters now may differ from what mattered last week.
Do a bounded piece of work. Choose an action that can advance the goal or reduce an important uncertainty. Keep its cost and consequences within the authority you have given.
Check what actually happened. A finished artifact is evidence of production, not necessarily evidence that the goal advanced. Inspect the result in the system where it matters. An agent reporting success is not enough.
Return the learning to the work. Update the current plan, evidence, decision, or operating guidance that the next run will read. Preserve what remains uncertain and name the next useful action or review condition.
A schedule answers when to look again. It does not, by itself, connect results to decisions. Repeating the same task becomes a learning loop only when the observed result can change what happens next.
Feedback can support continuing the approach, changing it, pausing, or asking for a decision. Sometimes the evidence supports no change. Record that reason instead of inventing an improvement to make the loop look active.
Let feedback reach the right level
Some feedback changes how the work is done. A confusing explanation may call for a clearer example. An expensive production step may justify a different method. The goal stays the same while the approach improves.
Other feedback challenges the approach itself. Perhaps the intended audience needs a different kind of explanation, or the production budget makes the original strategy impractical. Then the loop should return to the strategy or ask the goal owner to reconsider the scope.
Goals can change, but changing the destination is different from improving a route. Preserve who made that decision and why. Do not quietly lower a target to turn a disappointing result into success.
A changed goal can also make an old plan irrelevant even when all its facts remain correct. When direction changes, revisit the work that depended on it. Keep contrary evidence and unresolved disagreement visible: the goal should direct attention, not determine which facts are allowed to survive.
The loop's procedure can also change. Repeatedly missing evidence or producing work that nobody uses is a reason to revise what the loop reads, checks, updates, or escalates. Compare the revised procedure with the previous approach before treating it as a better default. More frequent runs are not the only possible improvement.
See the difference across several runs
Consider an illustrative channel experiment. Viewers leave several tutorials before the practical demonstration. An agent proposes showing the result earlier. That is a hypothesis, not proof of why people left.
After an authorized test, the agent compares the response with reasonably similar videos and records the limits of the comparison. Better viewing figures may be useful, but the original goal still includes a returning audience and sustainable production effort. One improved number does not settle the whole question.
The reusable result belongs in the current audience and production guidance: what was tested, what the evidence suggested, what remains uncertain, and whether to keep or revise the approach. A later agent should be able to recover that understanding without reopening the original conversation.
The next run can then choose a more informed test rather than repeat the first suggestion. Improvement is not guaranteed on every run. What should improve is the ability to make the next decision from evidence rather than forgotten history.
Several loops can serve one outcome
A channel may eventually need separate research, production, audience-learning, and maintenance loops. Each should explain how its work supports the broader outcome and where its findings return.
A production loop can become faster while making less useful videos. A research loop can produce excellent notes that nobody uses. A maintenance loop can reorganize documents without removing any obstacle to real work. Local success matters only in relation to the outcome it is meant to support.
Shared goals and constraints help the loops reconcile these tradeoffs. Findings from audience learning can change production priorities. Production costs can change the strategy. The higher-level review can pause a loop that no longer earns its effort.
Start with one useful loop. Split it only when separate responsibilities, evidence, or review needs make that helpful. One agent may perform several kinds of work; several agents may contribute to one goal. Neither arrangement requires a fictional employee chart.
Different people and organizations may also have different goals. Make dependencies and disagreements explicit rather than silently replacing them with one objective.
Keep the goal and its evidence visible
A person or a new agent should be able to answer: what are we trying to improve, what do we currently believe, what has actually changed, and what happens next?
Begin with one maintained document when that is sufficient. Keep the current goal, the approach and its rationale, evidence of results, important constraints, and the next action or review point together. Link to detailed work only when it has a distinct purpose. A pile of session summaries is a poor substitute for a current answer.
Use observations that bear on the intended outcome, not only convenient activity counts. For some work that means measurable results. For other work it means an explicit quality review or evidence that a difficult uncertainty was resolved. Retain the costs and tradeoffs alongside the result.
The same discipline helps when building a product or organization: work backward from the desired outcome to identify what must be true, then test the smallest useful step through real use. A long-term goal guides design choices; it does not require building every possible future mechanism before learning begins.
Use Oddlynew for the state between runs
Oddlynew holds the shared goals, decisions, evidence summaries, guidance, and loop definitions that people and compatible agents read and update. Your chosen agent supplies the reasoning and performs authorized work through the tools available to it.
Creating a loop definition does not make it run. Automatic recurrence needs an actual schedule or event source in an authorized external runtime. The goal is also not permission to spend money, publish, change access, or make commitments. State those boundaries separately.
In practice that runtime is an agent you choose: one you work with, or one on a schedule you set with a single sentence. See Your agents run your Loops.
Loop and Graph Engineering explains how to connect the evidence and the documents each loop updates. For a more developed recurring system, Make Every Agent Run Improve the Next separates the loop definition, the runtime that executes it, and the evidence from each attempt.
Start with one useful cycle
Ask your connected agent:
Read this organization's guidance and existing work. Help me make progress toward [my goal]. State your current understanding of success, the important constraints, and what remains uncertain. Propose the smallest useful next action and carry it out only within my authorization. Check the result, update the documents that should guide future work, and leave a clear next step. Explain what evidence would make us change the approach or reconsider the goal.
After the cycle, check both the result and the handoff. The work should have produced something useful, resolved a meaningful uncertainty, or identified a specific blocker. The next run should be able to recover that outcome and continue without reconstructing it from chat.