Backpressure is a concept that involves pushing back against an agents output by forcing certain checks or constraints on the AI's outputs. For example, you may choose to use a strongly-typed language which forces the agent to have well-typed code, thus reducing the chance of certains types of errors. Other forms of backpressure (not exhaustive) include running typechecks, linters/formatters, unit tests and visual tests, often in a pre-commit hook. By doing this, you can guard each unit of work that the agent produces with built-in quality gates.
If the agent hits one of these gates, like a failing test, it will then need to make changes to it's output to pass that test and thus ensure quality. Software engineering has now reached a point where it is now critical to spend time designing and implementing your backpressure. A great post explaining backpressure in detail is found here.
Context windows can be seen as the working memory of an LLM and contain not only your messages to the model but also the responses the model gives you, it's system prompt, any tools, MCPs, or skills it has access to as well as anything "thinking" tokens it has generated.
Usage of these windows is often expressed in a percentage of tokens used within the window and it's generally assumed that you don't want to use more than 60-70% of the context window at a time as you may enter the "dumb zone" at which point the agents responses get less clear and may become more confused with what you were trying to do in the first place as it biases information at different points in the large context. A nice example of this is the 8-needle benchmark whereby an LLM's context window is filled up and a randome 8 "needles" are littered amongst it that the LLM is tested to see if it can retrieve. Event SOTA models at the time of writing (20-03-2026) are unable to achieve a perfect score yet.
Tools for an LLM can be see just like a function for a regular program. They have a name, and often are implemented as as deterministic function the LLM can choose to call and have the result added back to it's context. For example, a bash tool might take an argument which is a bash command which is ran on the host machine and then returned to the LLM. These tools give the LLM arms and legs to interact with the machine it's on and occasionally external system through MCPs and CLIs.
Skills are a concept supported by a number of common agents, such as Claude Code, where they are essentially saved prompts that can be lazy-loaded into the agents context. Skills have a name and often are markdown files with frontmatter that include a description of what the skill does and when it should be used. This frontmatter is usually included in the agents system prompt so the agent knows that the skill exists and if the agent decides (based on the description) that it needs that skill, it can call a tool (something like load_skill(name)) to pull the full skill file into it's context window to start executing the skill.
This pattern is useful for creating short-hand commands for common prompts you may use but is also useful for helping guide an agent towards a particular outcome by helping shortcut thinking rather than asking it to achieve some goal and spending a lot of it's context figuring out how to do what it needs to. For example, a commit-and-push skill might include exact git commands to run, exact formats for commit messages that you expect and any other information that may result in the agent hitting an error if it wasn't told up front (and then resulting in the agent needing to troubleshoot before taking the correct route.)