How To Achieve Almost Any Goal In 3 Easy Steps + Why AI Agents Work
David Colaursso
Co-director, Suffolk's Legal Innovation & Tech Lab
This is the 46th post in my series 50 Days of AI. Previous Post | Next Post
We recently reworked the syllabus for the LIT clinic and in doing so, the following gem lost its home. It was part of an earlier version that billed itself as a handbook. My co-teacher suggested I find a new home for it. So, why is it here? Because despite being written back around 2019, it perfectly captures how and why AI agents work. That is, AI agents simply follow these steps. If you give an agent the job of writing a story and the ability to pick up a tool, it will keep plugging along. This will make sense when you get to the end and after you build today's prompt. Trust me.
Today's prompt creates a very small review loop. It's based 500 Characters? I’ll Make It Fit!. Unlike that prompt which sometimes produced texts larger than 500 characters, this one checks the reply length and re-runs itself if it's too big.
The 3 easy steps
- Craft a believable story, set in the present, that ends with The Goal being achieved.1
- Break the story into chapters, and have those on Team Goal do their best to act out the first chapter.2
- After reality deviates from the script, the chapter ends, or the passage of some set time, repeat these steps until either The Goal is met or it becomes impossible to craft a believable story.3
Footnotes
0. This post began its life as a playbook for students working as part of the LIT Lab’s consultancy practice. Originally, I was shooting for something like the Digital Services Playbook. Unfortunately, my early drafts relied too much on nomenclature and industry norms unfamiliar to the average law student. I considered zooming in (providing context and explanation for every reference), but that seemed like a recipe for infinite regress. So I opted to zoom out and focus on general principles. This has freed me to use specific examples for illustrative purposes without the need for them to be all encompassing. It also allows me to highlight similarities between multiple systems for getting things done.
To avoid the trap of just telling folks to draw the Owl, I’m providing ample context for each of the steps through footnotes. Yes, this is a bit of a gimmick, and the title above is total click bait.
There are only three steps, but it takes over a thousand words to imbue them with meaning. It’s worth noting, however, that this is the case for many endeavors. Jargon gets a bad rap, and deservedly so when used to obscure meaning, but a good term of art or framing mechanism, once understood, can stand in for paragraphs of exposition. With the creation of such conceptual building blocks, discussion and reasoning can move more quickly. This is especially true for collaborations, like what we'll be doing, where a reliable shorthand eases communication.
Consider that the job of every prosecutor in a criminal trial can be boiled down to ten words: prove the elements of the crime(s) beyond a reasonable doubt. Those ten words are a good guide to action. Zoom out more, and you can describe a prosecutor’s whole job in two words: do justice. Such drastic distillation comes with benefits and risks. Done well it can provide clarity and direction. Overdo it and you’re left with pablum. Worse yet is the space between, where clarity is an illusion, everyone relying on a sui generis interpretation, secure in the belief their understanding is shared by all. That being said, let’s see if we can arrive at a common understanding.
1. Believable is doing a lot of work in this sentence. Here, it’s roughly synonymous with realistic or probable.
In order to tell a believable story, you have to truly understand your “characters” and their “motivations.” Sometimes you’re lucky, and your characters aren’t people. This is where the hard sciences shine. If asked to tell a story about how to place a satellite in geosynchronous orbit, the primary players (i.e., the satellite and the Earth) find themselves constrained by a set of well-understood physical laws. To achieve geosynchronous orbit we have to get the satellite to a specific distance above the Earth traveling with some set horizontal velocity. That’s it. This is an engineering problem because the story we’re asked to craft ends with an easily stated objectively measurable goal, the achievement of which relies on what you might call well understood “motivations” (physical laws).
Once your story includes considerations like how to pay for things, source materials, motivate employees, and clear political hurdles, its nature becomes much more speculative. No longer can the story be told by equations alone. We are speaking of storytelling as simulation. That is, in order to tell a believable story, we construct a series of probable events that result in the desired outcome based on our understanding of how the world works. The scope of our story and the understanding needed to craft it depend greatly on the goal(s) we seek to achieve. So to do this step well, we have to know what we want and enough about the world to tell a story that moves us from the world as it is to the world we want it to be.
Our initial story is unlikely to survive engagement with reality. So it’s important that we’re able to recognize success and change course when we fall short. Consequently, our goals must be measurable. For example, it’s not enough to say that we want to build or do a great thing. We have to define what we would see if we were to build or do a great thing. This doesn’t have to be an objective measure per se. Subjectivity is fine. If by “a great thing” we mean “Sally thinks it’s great,” or “demographic X thinks it’s great,” we can work with that. We just need to identify a measurable success metric. So our metric might be, “Does Sally say she thinks it’s great?” Admittedly, some goals are harder to measure than others, and there is a temptation to redefine our goals to correspond with easily measured metrics. Fight that temptation. Your goals are a reflection of your values, and you shouldn’t compromise them because something is hard (unless you value them less than the required effort). Pragmatism is productive, but it’s not an excuse to be lazy.
2. As you can see from step three, the end of a chapter is notable for the fact that it can trigger the creation of a new story. So chapters act as built-in checkpoints. Like the story’s ultimate Goal, they should come with measurable conclusions, but their completion should also tell us something about our overall progress, so we know if we’re moving in the right direction. If your goal is product development, this is comparable to focusing on a minimum viable product (MVP) for each chapter—what some might call iterative prototyping.
As for Team Goal, this is just the collection of folks working to achieve The Goal. Your team may be a formal working group or just a collection of folks with common cause. Heck, it may be a team of one. What’s important for our purposes is that the team members are willing to work together and live out their parts in the story. Consequently, it has to be a shared story (one all the members buy into). One of the best ways to make this happen is to have the team contribute to the story’s creation. After all, if they’ll be the ones acting it out, they’re likely to have some suggestions. This of course is just a reflection of what I find to be a believable story. I clearly think that giving folks agency over a story is motivating. Maybe I’m right; maybe I’m wrong. Either way, it’s stories all the way down.
3. The important point here is that there be some regular reassessment. If things go off the rails the need for reassessment will be clear, but you need to build in structures that mandate periodic evaluations. As discussed in footnote 2, chapters provide convenient opportunities for such. Setting a fixed time to check in can act as a fail safe should a chapter take longer than expected to run its course. Whatever the triggering event, step 3 is the point at which your past work becomes prologue for a new story. If you’re lucky, you can just re-number the chapters from a prior version, advancing one chapter closer to your goal. If you’re really lucky, you’ll find that you’ve reached your goal. More likely, however, you’ll have to make a few adjustments based on what went wrong and what worked well, and occasionally, you’ll discover that there just isn’t a believable story to tell.
So what?
These steps probably sound familiar. They come in many incarnations and clearly belong to a family of iterative processes like the scientific method, design thinking, and Agile software development. It’s also easy to see in them reflections of cybernetics and Hosfteter’s strange loops. There is nothing more central to the human experience than telling stories. Over the semester, we may discuss methodologies like Agile, Kanban, design thinking, GTD and the like because you’ll find their followers and evangelists out in the wild. You may be tempted to ask, “which one is right?” but that’s probably the wrong question. In my experience, any structured method for getting things done is often better than no method. These methods embody mental models that try to describe the world (believable stories), and as George Box observed, “All models are wrong, but some are useful.” So remember that since they’re “wrong” they should start, not end, conversation. Avoid dogma.
To know whether or not a model is useful, you have to ask “compared to what?” Models do not exist in isolation. Their adoption will replace something. Again, structure often beats its absence. Maps are models of the world. They don’t show every inch of the territory they describe. So they’re “wrong,” but this doesn’t mean they aren’t useful. Context matters.
When you boil the sum of productivity hacks and management advice down to their essence, they’re all about capturing your goals, crafting believable stories to guide action, testing these stories against reality, and refining them over time. With this in mind, you can better evaluate all that friendly advice. Just ask yourself what it contributes to crafting better shared stories and helping folks stick to the script. If the process includes the word “innovation” or “design” it’s probably concerned with telling better stories, if it’s talking about “productivity” or “efficiency” it’s often about helping folks stick to the script (usually by telling a story that helps guide action). Either way, this advice holds, “do what works.”
Let's build something!
We'll do our building in the LIT Prompts extension. If you aren't familiar with the LIT Prompts extension, don't worry. We'll walk you through setting things up before we start building. If you have used the LIT Prompts extension before, skip to The Prompt Pattern (Template).
Up Next
Setup LIT Prompts
LIT Prompts is a browser extension built at Suffolk University Law School's Legal Innovation and Technology Lab to help folks explore the use of Large Language Models (LLMs) and prompt engineering. LLMs are sentence completion machines, and prompts are the text upon which they build. Feed an LLM a prompt, and it will return a plausible-sounding follow-up (e.g., "Four score and seven..." might return "years ago our fathers brought forth..."). LIT Prompts lets users create and save prompt templates based on data from an active browser window (e.g., selected text or the whole text of a webpage) along with text from a user. Below we'll walk through a specific example.
To get started, follow the first four minutes of the intro video or the steps outlined below. Note: The video only shows Firefox, but once you've installed the extension, the steps are the same.
Install the extension
Follow the links for your browser.
- Firefox: (1) visit the extension's add-ons page; (2) click "Add to Firefox;" and (3) grant permissions.
- Chrome: (1) visit the extension's web store page; (2) click "Add to Chrome;" and (3) review permissions / "Add extension."
If you don't have Firefox, you can download it here. Would you rather use Chrome? Download it here.
Point it at an API
Here we'll walk through how to use an LLM provided by OpenAI, but you don't have to use their offering. If you're interested in alternatives, you can find them here. You can even run your LLM locally, avoiding the need to share your prompts with a third-party. If you need an OpenAI account, you can create one here. Note: when you create a new OpenAI account you are given a limited amount of free API credits. If you created an account some time ago, however, these may have expired. If your credits have expired, you will need to enter a billing method before you can use the API. You can check the state of any credits here.
Login to OpenAI, and navigate to the API documentation.
Once you are looking at the API docs, follow the steps outlined in the image above. That is:
- Select "API keys" from the left menu
- Click "+ Create new secret key"
On LIT Prompt's Templates & Settings screen, set your API Base to https://api.openai.com/v1/chat/completions and your API Key equal to the value you got above after clicking "+ Create new secret key". You get there by clicking the Templates & Settings button in the extension's popup:
- open the extension
- click on Templates & Settings
- enter the API Base and Key (under the section OpenAI-Compatible API Integration)
Once those two bits of information (the API Base and Key) are in place, you're good to go. Now you can edit, create, and run prompt templates. Just open the LIT Prompts extension, and click one of the options. I suggest, however, that you read through the Templates and Settings screen to get oriented. You might even try out a few of the preloaded prompt templates. This will let you jump right in and get your hands dirty in the next section.
If you receive an error when trying to run a template after entering your Base and Key, and you are using OpenAI, make sure to check the state of any credits here. If you don't have any credits, you will need a billing method on file.
If you found this hard to follow, consider following along with the first four minutes of the video above. It covers the same content. It focuses on Firefox, but once you've installed the extension, the steps are the same.
The Prompt Pattern (Template)
Let's build a shortener that checks its own work. Instead of asking an LLM to make selected text shorter and simply hoping it meets our limit, we'll connect four LIT Prompts templates. The first drafts a shorter version; the second checks its length; the third makes another pass when needed; and the fourth displays the result only once it passes the test. Our target is strictly fewer than 500 characters.
Like our earlier examples, these templates mix plain language with variables inside double curly brackets. {{highlighted}} is the text you selected in the active browser tab. When one template hands its output to another, {{passThrough}} carries that output forward. If the output is a JSON object, we can access its values with placeholders such as {{passThrough["text"]}} and {{passThrough["length"]}}. For more, see the extension's documentation.
To use these prompts, highlight some text in your browser, open LIT Prompts, and choose 🗜️ Shorten to under 500 characters. That's the only visible entry point; the other three templates run automatically as part of the chain.
1. 🗜️ Shorten to under 500 characters
Here's our starting template. We ask the LLM to cut at least 20% from the selected text, preserve its essential meaning, and return only the revision. Its output is passed to the next template rather than displayed as the finished answer.
Here's the template's text:
You're a helpful editor, and you're going to trim some selected text. First, compress it by at least 20%, keeping the main points, important facts, and intended meaning. Try to get it under 500 characters without sacrificing essential information. Return only the shortened text: no introduction, explanation, quotation marks, or character count.
{{highlighted}}
And here are the template's parameters:
- Output Type:
LLM. Runs the shortening instructions through an LLM. - JSON:
No. We want plain text that the next template can count, not a JSON-formatted LLM response. - Output To:
Hidden. Hides the first draft while still passing it to the next template. - Post-run Behavior:
Shortener: check character limit. Automatically runs the JavaScript check after the LLM responds. - Hide Button:
unchecked. Keeps this starting template visible in the extension popup. - Run in New Tab:
unchecked. Does not open a new tab to run this step.
2. Shortener: check character limit
Here's where we add the test. This template uses JavaScript, not an LLM. It reads the preceding draft from passThrough, trims leading and trailing whitespace, and counts its characters with JavaScript's .length. If the count is below LIMIT, it routes the result to the display template; otherwise, it asks the LLM to shorten the draft again. The returned object's next field controls the next step through the DYNAMIC post-run behavior.
Here's the template's JavaScript:
// Change this one constant to use a different character limit.
const LIMIT = 500;
// The preceding LLM prompt returns plain text through passThrough.
const shortened = String(passThrough == null ? "" : passThrough).trim();
const characterCount = shortened.length;
// DYNAMIC reads "next" from this returned JavaScript object.
return {
next: characterCount < LIMIT ? "Shortener: display final text" : "Shortener: shorten again",
text: shortened,
length: characterCount,
limit: LIMIT
};
And here are the template's parameters:
- Output Type:
JavaScript. Runs the code shown above instead of sending a prompt to an LLM. - JSON:
No. We are not requesting a JSON-formatted response from an LLM; the JavaScript itself returns an object. - Output To:
Hidden. Keeps the internal character count and routing result off the screen. - Post-run Behavior:
DYNAMIC. Reads the returned object’snextvalue to choose either the display step or another shortening pass. - Hide Button:
checked. This internal step should be triggered by another template, not selected directly. - Run in New Tab:
unchecked. Does not open a new tab to run this step.
3. Shortener: shorten again
If our check fails, this template gives the LLM the last draft, its measured length, and the limit. It asks for a fresh reduction without losing essential information, then sends the new version back to the same JavaScript check. That loop continues until a revision passes.
Here's the template's text:
You're a careful editor. Your last revision was {{passThrough["length"]}} characters, but it must be strictly fewer than {{passThrough["limit"]}} characters. Shorten it again. Aim to remove at least 20% of what remains, or more if necessary, while keeping essential facts, meaning, and readable grammar. Prefer concise wording over dropping key points. Output only the new, shorter text. Do not add an introduction, quotation marks, Markdown fences, or a character count.
Text to shorten:
{{passThrough["text"]}}
And here are the template's parameters:
- Output Type:
LLM. Sends the current text back to the LLM for another shortening pass. - JSON:
No. The LLM returns revised plain text rather than a JSON-formatted response. - Output To:
Hidden. Keeps the revised draft out of view until it passes the check. - Post-run Behavior:
Shortener: check character limit. Sends the revision back for another character count. - Hide Button:
checked. The checker should invoke this step automatically when a draft is too long. - Run in New Tab:
unchecked. Does not open a new tab to run this step.
4. Shortener: display final text
When the character check passes, this last template pulls the approved text from {{passThrough["text"]}}. It's a Prompt output, so it simply displays the text rather than making another LLM call.
Here's the template's text:
{{passThrough["text"]}}
And here are the template's parameters:
- Output Type:
Prompt. Substitutes the final text into the template without making an LLM call. - JSON:
No. The goal is to display plain text, not request JSON output. - Output To:
Screen Only. Shows the final, checked version to the user. - Post-run Behavior:
FULL STOP. Ends the chain once the checked text is displayed. - Hide Button:
checked. This step should run only after the checker confirms the character limit. - Run in New Tab:
unchecked. Does not open a new tab to display the result.
All four templates have JSON mode off and leave the model and other optional model settings blank (so the LLM steps use your configured defaults). Only the first template has a visible button. In the two LLM templates, the output is hidden because the next step still needs it; the final step shows just the checked result. Note that the check uses characterCount < LIMIT, not <=: with LIMIT = 500, an accepted result has at most 499 JavaScript string characters. Because it uses JavaScript's .length, some Unicode characters, such as emoji, can count as two code units.
Want a different limit? Change const LIMIT = 500 in the JavaScript checker, and update the wording of the two LLM prompts so they aim for the same number. The model still makes "editorial" choices, so review the final result for missing nuance or mistakes.
Working with the above templates
You could create all four templates in LIT Prompts by copying their text, output types, and post-run behaviors one by one. The easier route is to download the complete prompts file below and upload it from the extension's Templates & Settings screen. This preserves the links between templates, including the dynamic branch and the retry loop.
The download contains all four templates and their settings, ready to import. It is embedded in this page so the button downloads this exact prompt set.
Kick the Tires
It's one thing to read about something and another to put what you've learned into practice. Let's see how this template performs.
- Make it your own. Find and highlight a big chunk of text. Then shrink it to less than 500 characters.
- Mix it up. Edit the code to set a limit other than 500 characters. See how it goes.
TL;DR References
ICYMI, here are short summaries of resources linked above. If you didn't click through earlier, these are good places to explore the ideas behind the three steps—and the tools used to put them into practice.
- Digital Services Playbook. This guide to building effective government digital services organizes practical advice into 13 "plays," including understanding users, working iteratively, and measuring results. It's an example of how a shared playbook can turn broad goals into concrete practices.
- How to Draw an Owl (Know Your Meme). The familiar two-panel joke starts with simple circles and jumps straight to a finished owl, skipping all the difficult work in between. It's a reminder that advice can sound simple while omitting the detail needed to act on it.
- Minimum Viable Product (MVP). An MVP is an early version of a product with enough functionality to put an idea in front of users and learn from their feedback. In our three-step framework, each chapter can serve a similar purpose: a manageable milestone that tests whether the larger story still seems believable.
- Scientific Method. Scientific inquiry uses observations, explanations, and tests to learn how the world works. The resulting evidence can support, challenge, or refine an explanation—a close cousin of the cycle of telling a believable story, checking it against reality, and revising it.
- Design Thinking. This family of design approaches emphasizes understanding people's needs, exploring possibilities, making prototypes, and testing them. It treats initial ideas as things to learn from rather than answers to defend, making iteration central to the process.
- Agile Software Development. Agile approaches favor incremental delivery, collaboration, and adaptation as teams learn more about their work. Instead of treating an initial plan as fixed, teams use short cycles and feedback to decide what to do next.
- Cybernetics. Cybernetics studies communication, feedback, and control in systems, whether mechanical, biological, or social. Its focus on how systems respond to information helps explain why regular checkpoints and course corrections matter.
- Strange Loops. Associated with Douglas Hofstadter, a strange loop occurs when moving through levels of a system leads back to the starting point. The idea offers a useful lens for thinking about self-reference and the way each revised plan is informed by the story that came before it.
- Kanban. Originating in Toyota's manufacturing system, kanban uses signals to coordinate work and avoid producing more than the next stage needs. Related approaches use visible workflows and limits on work in progress to help teams see where work stands and where it is getting stuck.
- Getting Things Done (GTD). David Allen's productivity method calls for capturing commitments, clarifying next actions, organizing reminders, and reviewing them regularly. It focuses less on dreaming up a destination than on helping people keep track of—and act on—the steps needed to get there.
- LIT Prompts: Prompt Templates. The extension's documentation explains how templates combine instructions with placeholders for user input or selected text. Those templates are the building blocks for the shortening workflow shown above, including the handoff from one step to the next.
Summary based on LLM summarization.





