With the progress of large language model capabilities, the advancements of agent harnesses, and the introduction of agentic development workflows like using the /goal skill, agents are now capable of completing long-running, complex work tasks. Language models are now intelligent enough at a low enough cost to make running agents independently for hours economically feasible. These long-running agents are the key to enabling AI to autonomously work on the world’s most complex problems.
However, long-running agents introduce new difficulties not previously encountered in human-guided agents due to the build-up of context as a long-running agent works. This “context rot” causes agent reasoning and end-to-end task performance to decline.
Thus, the key to effective long-running agents is proper context engineering. Fundamental to proper context engineering is designing great skills for long-running tasks. Skills are the primary method agents are exposed to tools and information necessary for task completion. Managing skills not only avoids overloading an agent’s context window with task information, but also reduces the context rot incurred from agent reasoning itself.
The information below is a summary of best practices for developing skills for long-running research agents.
Use the open Skill standard
Developing these skills is easiest by adhering to the open skills standard developed by Anthropic or a similar format. We use this for two reasons:
Progressive disclosure: Agents can read metadata about what a skill is used for and only load the full skill context when the skill is needed.
Easy sharability: The open skills standard enables skills to be created and shared across agents.
Progressive disclosure is particularly important for long-running agents as they’ll consume data from many sources and perform actions with that data. Progressive disclosure enables keeping skills small even as workflows become complex (more on this in the next session). This requires loading many skills to understand workflows and tool use, and can quickly fill the agent’s context window.
Sharability is particularly handy because long-horizon, complex tasks require tool and data access across multiple systems. When working in an enterprise setting with multiple organizations and teams, it’s a huge velocity increase to be able to use an agent skill another team has developed for their services. The team with more knowledge of the system can maintain and develop the skills giving agents access. Meanwhile, another team can focus on enabling end-to-end agent capabilities interfacing with that system.
Additionally, the open skill standard enables sharing skills across the AI community. In a high velocity, constantly developing field, this open knowledge is helpful for getting the most out of agentic development. I highly recommend you start a skills repository of your own to share your workflows and skill findings with others. You can find mine here.
Be mindful about how you write the skills
Not all skills are equal, and for end-to-end agent workflows, how they are written represents one of the single biggest performance gains. A good motto when developing these skills is “Less is more”. There are a few best practices to make reaching the primary goal of getting more information to agents with fewer tokens easier:
Each skill should teach one thing. Keep skills lightweight and under 1500 tokens wherever possible. This is made easier by communicating directly and succinctly, removing unnecessary words and phrases (“make no mistakes” is no longer a helpful performance trick—current models are too smart), and ensuring information isn’t repeated. Longer skills should either be split into multiple skills or split into a skill with appropriate reference files.
Skills should be workflow-oriented. Tell the agent exactly what to do and how to do it by using the skill. Instead of a reference with general information, make the skill step-by-step instructions. Agents follow instructions well, and it keeps them from having to do additional reasoning about what to do next.
Provide concrete examples. Provide specific examples in your step-by-step instructions of how the agent should do something. To save on both time and context, this limits the reasoning required for an agent to use a tool correctly. For example, an explicit example of how to run a tool and with what arguments will tell the agent everything it needs in a line of text, instead of having it determine the right arguments for a CLI tool via searching for documentation and trial-and-error.
Don’t confuse the agent. Agents are smart and will naturally search for information related to their task. If an agent can find contradictory information for a task, it will perform significantly worse, wasting tokens on reasoning and trial-and-error. Take care to ensure your skills don’t include contradictory information and your agent can’t find contradictory information in documentation. This is made easier by turning skills into workflows, documentation reference material, and following the other best practices listed in this section.
In my skills repo, I’ve included a /skill-refiner skill that adjusts skills to follow the best practices above. You can easily pull this into your agent harness using Vercel’s Agent Skills resource. Even more simply, you can ask your favorite agent harness to do it for you.
Know what to turn into a skill
The rule is simple: Anything outside of its core reasoning loop that you want the agent to do.
The ability to reason about a complex task and act as necessary is the benefit of agents. To do that for you, lean on your model and agent harness. By explicitly providing information for the actions you expect it to do, make the reasoning easier for the agent.
To be more explicit, there are a few low-hanging fruits that should immediately scream “This should be a skill”:
Repeated work. The nature of large language models means the agent can approach the same task in variable methods between different runs. Creating skills for repeated work directs on how to be consistent in this work and perform it as you intend.
Deterministic work. The non-deterministic nature of language models enables agents to complete complex tasks, but it also makes their output less consistent and reliable. All work an agent performs that can be done deterministically should be outsourced to a tool and a skill should be created telling the agent how to use it.
Workflows. To make it easier for the agent to follow instructions end-to-end, any step-by-step process should be explicitly defined in a skill. By greatly reducing agent mistakes on long-horizon tasks, this limits the token usage spent on reasoning.
Here’s a quick infographic to summarize the three sections above:
Long-running agents hold the potential to solve humanity’s most difficult problems. Give them some excellent skills and they’ll be much more performant and reliable.
Thanks for reading! I’ve included some additional reading below if you’re interested.
Always be (machine) learning,
Logan
Further reading
If you want to learn more about long-running agents, their harness, and developing skills for them, here are a few good resources:
OpenAI’s guide to using skills with Codex. An overview of the /goal skill is along with when and how to use it.
Addy Osmani’s blog post on long-running agents. A general overview of long-running agents.
OpenAI’s guide to skills. A brief guide on how to write skills for long-running agents.
Anthropic’s guide to effective harnesses for long-running agents. Information on the harness side of long-running agents.
loganthorneloe’s skill repo: Feel free to check out my skills. Also, feel free to paste your skill repo in the comments of this post.
There’s an organizational layer to this that I find really interesting. Turning repeated work into a skill doesn’t just reduce context or improve reliability. It decides which parts of judgment should stop being rediscovered each time and become repeatable infrastructure.
That makes skill design partly a question of what we choose to stabilize. Which behaviors should become consistent enough to reproduce, and which should remain inside the reasoning loop because the context still matters?
One the leanest pieces out there explaining so nicely. Thankyou for putting it together!! 🙋🏻♀️