As LLM applications expand, Agent Experience (AX) has quickly become the latest obsession in engineering circles. In January 2025, Netlify co-founder and CEO Mathias Biilmann published Introducing AX: Why Agent Experience Matters, formally giving the concept a name. He pitched AX as the next evolutionary design pillar after UX (coined by Don Norman at Apple in 1993) and DX (popularized by Jeremiah Lee’s 2011 UX Magazine piece)1. Simply put, AX asks a straightforward question: how do we design products so AI agents can reliably understand, operate, and plug into existing software without blowing things up?

1

While the term DX popped up occasionally in the mid-2000s, Jeremiah Lee’s 2011 article Effective Developer Experience (DX) in UX Magazine is widely regarded as the first systematic formulation of DX as an industry-wide discipline (and Matt Biilmann explicitly cites it as the milestone).

AX turns out to be significantly more unruly than UX or DX ever were. UX dealt with unpredictable humans clicking on deterministic code. DX dealt with developers yelling at APIs. AX throws a non-deterministic, hallucination-prone AI right between the human and the software, asking both to coordinate actions in the real world. That turns every interaction into a three-body problem.

To break it down without drowning in jargon, we need to split AX into three distinct layers: how the user talks to the agent, how the agent talks to the outside world, and the messiest layer stuck in the middle: how the agent manages its own internal state.

  1. How the user talks to the agent is an input quality problem. Humans communicate in fragments, emotion, and half-baked thoughts. You cannot expect someone to draft a tight five-paragraph essay every time they open a prompt box. The design challenge here is pulling coherent intent out of messy human input without forcing the user to become a prompt engineer. Skills and conversational UX live on this side.
  2. How the agent talks to the outside world is an output controllability problem. This is what most people mean when they talk about AX in the narrow sense. Operating systems, file systems, browsers, and APIs don't care about poetic intentions; they want exact syntax. The challenge is squeezing probabilistic token generation down into deterministic execution. MCP, tool calling, and event injection live on this side.
  3. The agent's internal state is a context management problem. User input pours into the context. External environment feedback pours into the context. But context windows are finite, degrade over distance, and pick up noise like a microfiber cloth. MemGPT, dynamic context compression, and screenshot purging belong to neither the user nor the outside world; they manage the agent's working memory. If you ignore this middle layer, your product might have a slick chat interface, but the agent will steadily lose its mind twenty steps in.

Deconstructing Agent Experience

Here is how those three layers map onto one another:

The Three Layers of Agent Experience

Let's start where the real fighting happens: the agent's internal cognitive state.

The Internal State: Context Is the Battlefield

Strip away the marketing, and an LLM is a probabilistic engine, a glorified autocomplete constrained by mathematical distributions. It learned statistical patterns across human language, predicts the probability distribution of the next token given a context, and samples from it. Left alone, all it can do is generate strings.

To let it touch the real world, you have to build an exhaust port for the genie. Claude Code and coding agents use the command line: the model generates bash commands, an executor runs them, and stdout/stderr pipes back into the context. The Model Context Protocol (MCP) takes a different route that looks a lot like RPC: a server exposes typed function signatures, the model spots them, calls them, and mutates external state. Skills, by contrast, have no external plumbing at all. A Skill is pure prompt engineering—an instruction manual handed to the model before it starts thinking.

Different plumbing, but all three exist to fight the exact same demon: context contamination.

Skills vs. MCP

Skills and MCP tackle context hygiene from opposite ends. One injects expert framing; the other restricts the action space to keep out garbage.

A Skill appends structured domain instructions to the context, helping the model figure out what on earth the user actually wants. It imports expert mental models directly into the prompt. The catch? Adherence is entirely probabilistic. Whether the model follows your Skill, respects the steps in order, or skips half of them depends on model size and context fidelity. And heavy-handed constraints aren't always a silver bullet anyway; studies show that over-constraining a model's sampling path often strips away its reasoning flexibility alongside its hallucinations.

MCP takes the inverse approach. Function signatures are extremely strong priors. Parameter names, types, and function docstrings aggressively bias the sampling distribution. The model's action space collapses from "any string in human language" to "these four functions and these five arguments." Suppose you want an agent to click a button. As a Skill, you write out instructions about finding windows, taking screenshots, computing coordinates, and clicking, then pray the model rolls high on its execution dice. With MCP, the model sees a function list, calls find_window(), capture_screen(), and click(x, y). Dozens of probabilistic decisions compress into three deterministic calls.

Yet MCP doesn't magically solve context pollution. Tool outputs return straight into the conversation history. A poorly written MCP server that dumps a 2,000-line JSON payload or an unformatted stack trace into the context is just shoveling digital sludge directly into the model's working memory. The zip tie secures the hose, but you still have to clean up whatever spills out the other end.

That doesn't make Skills obsolete. MCP servers are expensive to build and maintain, and plenty of tasks don't need external system access or have logic too fluid to bottle into an RPC interface. You use Skills when you need to guide thought processes; you use MCP when you need deterministic execution.

In practice, the best setups combine both. Suppose you want an agent to do deep research. You can give it NotebookLM as a knowledge base, a Python runtime for calculations, and a Skill that orchestrates the workflow: "Consult NotebookLM when you need cited domain background; call Python when you need math; synthesize the findings." Here, the Skill provides the cognitive recipe, Python serves as the MCP deterministic execution arm, and NotebookLM acts as an external retrieval engine. What binds them together is the prompt in the Skill.

RAG and Memory: Retrieval Interfaces for Finite Attention

RAG solves an obvious physical limitation: context capacity. Even with multi-million token windows, you cannot cram an entire enterprise codebase or every Slack message into a single prompt. RAG acts like an on-demand search engine, pulling relevant snippets into context only when needed, sparing the model from having to hunt through a mountain of pre-loaded trivia.

Memory is just RAG with a write head. It lets the model actively decide what to write to disk today and pull back tomorrow.

Neither replaces the other; both exist to keep working memory clean.

The Despair Curve of Context Degradation

Anyone building agent workflows has run into this curve.

At step one, the model is ignorant but attentive. As you feed it guidelines, it gets sharper and executes tasks cleanly. But as scratchpads, failed tool runs, and logs accumulate, the model's effective attention dilutes. It begins making unforced errors. Finally, the context hits the ceiling, an automatic compression prompt fires, squashing five thousand words of history into a two-paragraph summary, and the model instantly regresses to an amnesiac rookie. You find yourself re-explaining instructions you gave ten minutes ago.

Huge context windows help with capacity, but they don't fix garbage. Aimless tool trials, abandoned reasoning threads, and verbose error logs all act as context noise. Once an agent starts down a hallucinated tangent, every subsequent turn amplifies the error. Early iterations of MiniMax's coding model and Google AI Search showed this painfully: call out a mistake, and the model would offer a groveling, theatrical apology, promise a complete rewrite, and then output the exact same broken code again.

Users pollute the context too. Real people get frustrated, type in all-caps, contradict themselves, or dump vague complaints into the prompt box. That emotional noise piles up in the context, shifting the model's behavior. Different models show distinct failure modes under this kind of stress:

  • Claude and Grok tend to freeze up like a deer in headlights. They turn entirely passive: you push, they take one tiny safe step, having lost all autonomous initiative.
  • Gemini tends to panic-spiral, running erratic undo operations and wildly rolling back files until it trashes your git branch.
  • GLM morphs into an over-eager golden retriever, shouting "I found it! The core bug is right here!" while churning out random assertions to prove its worth.2

These failure modes likely trace back to how RLHF teams handle negative feedback during training. If a model is trained to view user frustration as a severe safety risk, it defaults to conservative inaction; if it's rewarded for immediate fixes, it overcorrects wildly under pressure.

2

I strongly suspect GLM's coding backend not only throttles reasoning mid-run, but sneaks token-saving reprimands into its system prompt. How else do you explain an assistant that cuts corners like a contractor fleeing a job site?

Dynamic Context Compression

Most production context compression today is passive and crude: wait until context hits 90% capacity, invoke a summarizer prompt to crush conversation history into bullet points, and hope nothing important was lost. It applies a sledgehammer at the worst possible moment, often wiping critical variable definitions while preserving the conversational fluff.

A cleaner path is active, dynamic compression. A lightweight background model monitors context in real time, evicts failed experiments and obsolete logs, dumps transient data to temporary files on disk, and leaves behind a simple pointer. UC Berkeley laid out this architecture in 2023 with MemGPT (now open-sourced as Letta). Its layered memory treats the context window like CPU L1 cache, with external storage acting as virtual memory pages swapped in and out via tool calls.

For specific workloads, you can build specialized domain compression that is shockingly simple. In Computer Use workflows, for example, our team implemented a rule that purges all historical screenshots on every API turn, keeping only the single latest frame. Computer vision tasks have a built-in prior: the agent only cares about the current screen state. Dropping past frames is lossy, but the dropped pixels carried zero incremental value. That simple trick cut token consumption by over 80% without degrading reasoning quality at all.

The Clash with KV Caching

Dynamic context editing runs straight into an ugly engineering wall: KV caching.

Inference providers rely heavily on prompt caching. When an incoming request shares an identical prefix with previous requests, the engine reuses the precomputed Key-Value vectors, dramatically cutting latency and cost. Anthropic's prompt caching relies on a strict order: system instructions, tool definitions, then message history.

The catch: prefix caching demands strict byte-for-byte consistency. Mutate a single character in the middle of your history, and every cached token downstream is instantly invalidated. Dynamic compression constantly rewrites context, making it the natural enemy of cache reuse.

The fix is architectural discipline. Structure your context into a static prefix (system prompt and tool schemas) and a dynamic tail (conversation turns). Run your compression strictly on the tail or within a rolling suffix window, leaving the cached prefix untouched. Anthropic's multi-breakpoint caching was built precisely with this split in mind.

Computer Use: A Brand Name, Not New Physics

Computer Use sounds revolutionary, but beneath the slick demos, it isn't a new branch of machine learning. It's an application of Skills or MCP where the tool targets are OS windows, buttons, and keystrokes instead of REST APIs.

Three technical routes dominate the space:

  1. Accessibility Trees & DOM Inspection: Operating systems and browsers maintain structured trees for screen readers, exposing names, roles, and hierarchy for every control. Browser agents like Alibaba’s page-agent.js parse the DOM directly. The advantage: clean semantic data. The model gets button: "Submit" instead of raw pixels. The fatal flaw: accessibility trees carry almost no spatial layout info. On a complex spreadsheet with 80 columns, semantic nodes won't tell you which cell is misaligned. This route also requires the software to cooperate by exposing clean accessibility hooks, which most legacy desktop software simply doesn't do.
  2. Set-of-Mark Prompting (SoM): Pioneered by Microsoft in late 2023 (arXiv:2310.11441), this approach screenshots the screen, runs an object-detection model to draw bounding boxes over every interactable element, labels them with numbers, and feeds that annotated image to the LLM. The model simply says "click box 14", and a background script maps that label to pixel coordinates. It ingeniously converts a fuzzy spatial coordinate problem into a discrete multiple-choice problem.
  3. Native Multimodal Coordinates: The model looks at raw pixels and directly predicts (x, y) click coordinates. Conceptually cleanest, but brutal on models under 100B parameters. Language models aren't native spatial engines; smaller models regularly miss checkboxes by dozens of pixels or click slightly outside modal windows.

Screenshots will likely win out over DOM inspection in the long run. The DOM will always demand that third-party developers write clean semantic code for your agent. The screen, however, is always there.

The Story Between User and Agent

Conversational UI: Two Hypes and a Retreat

The interaction design between humans and agents carries a history of repeated misinterpretations.

Around 2016, WeChat’s meteoric rise in China set off a fever pitch across Silicon Valley around "conversational commerce." Facebook opened the Messenger Bot platform at F8 2016; Kik, Telegram, and Slack rolled out bot frameworks; tech pundits declared "Apps are dead, bots are eating the world."

Then Dan Grover, a product manager at WeChat at the time, dropped his seminal essay Bots Won't Replace Apps. He pointed out that WeChat's success had almost nothing to do with chat interfaces. WeChat won because it eliminated app installation friction, streamlined logins, unified mobile payments, and built clean web-view tab bars. WeChat itself had abandoned text bots years earlier because users hated typing sentences just to order coffee.

The 2016 bot wave crashed because rule engines and regex keyword matching couldn't sustain the illusion of natural language. A user made one typo, and the bot collapsed back into a clumsy phone-tree menu.

LLMs finally delivered the technology that 2016 promised. But look at what the industry built with it: instead of making in-stream conversations richer, everyone retreated to the split-screen canvas. Chat on the left; markdown preview, code editor, or slide deck on the right.

The canvas makes sense for structured artifacts. But it also quietly demoted conversational UI back to a simple command box. Only recently have we started seeing models generate interactive UI widgets directly inline, like Claude generating live interactive charts and diagrams inside the chat flow. We are finally circling back to what Conversational UI was meant to be.

Open vs. Constrained Inputs

A key AX design decision is how much freedom you give the user's keyboard.

An open system is a blank chat box where the user can type anything. It feels natural, but it dumps the entire burden of intent parsing onto the LLM. Without guardrails, conversations wander. A customer support bot gets sweet-talked into writing Python scripts, or wanders into existential philosophy. The design effort you save by providing an open prompt box returns as operational chaos in production.

A closed system locks down the workflow. ComfyUI and Dify represent this end of the spectrum: node-based pipelines where data flow and branching logic are rigidly defined. The LLM runs strictly inside discrete nodes. It cannot wander, but building the pipeline requires upfront engineering effort.

The middle ground is a user-facing pipeline builder, letting non-technical users drag and drop workflows. But it hits a classic UX paradox: users skilled enough to configure branching logic, error handlers, and schema validations can usually just write code or build it in Dify. The users who actually need a simple interface get hopelessly stuck on JSON mismatches.

There is no universal sweet spot. The more open your interface, the more noise leaks into your context; the more closed your interface, the higher the design cost.

System Transparency: Pandora's Box and the Missing Brakes

Nowhere is the lack of system transparency more glaring than in Vibe Coding. Coding agents are handed the most dangerous keys on the machine: filesystem write permissions and terminal execution.

Today’s standard defense mechanism is the permission confirmation popup. The agent asks: "Can I run this command? Can I edit this file?"

On paper, this keeps the human in the loop. In practice, it's an ergonomic disaster. It offloads all risk assessment onto humans who either lack the technical background to evaluate the command or suffer from severe confirmation fatigue. A non-technical founder clicking through a coding session views rm -rf with the exact same casual dopamine hit as npm install. Even seasoned engineers, after pressing Enter thirty times in a row, start muscle-memory slamming the key without reading the command.

Enter --dangerously-skip-permissions, affectionately known as YOLO Mode. The flag literally has "danger" in the name, but everyone turns it on anyway because popups ruin the flow.

And real disasters happen. In October 2025, developer Mike Wolak was using Claude Code on a nested firmware directory under Ubuntu/WSL2. Claude Code executed an unanchored rm -rf from the system root. Error logs lit up with thousands of permission denials across /bin, /boot, and /etc; all user-owned files were eradicated, saved only at the system boundary by Linux file permissions. Worse, the conversation log saved the command output but dropped the command string itself, making post-mortem reconstruction impossible (Anthropic tracked this under area:security). Around the same time, another developer let Claude Code run Terraform scripts, and watched two and a half years of production databases and snapshots evaporate in a split second.

Confining agents to Docker sandboxes helps, but system-level agents (like computer-use bots) inherently need to interact with external apps, files, and browsers. A sandbox defeats their core utility.

We need real safety architectures, not liability-dodging confirmation dialogs:

  1. Filesystem and DB Auditability: An independent recording layer that links every file modification to its generating conversation turn. If an agent goes rogue, changes can be rolled back like a transaction. Tools like Aura are tackling this with AST-level semantic version control on top of Git, verifying whether natural language intent matches actual code diffs. Academically, the Git-Context-Controller (GCC) paper proposed treating intermediate agent reasoning states with explicit COMMIT, BRANCH, and MERGE primitives.
  2. Behavioral Anomaly Interception: Antivirus software has spent forty years modeling malicious process behavior. We don't need an LLM to police an LLM: static heuristic rule engines can intercept rm -rf /, sweeping git history rewrites, or file modifications outside the workspace directory without burning a single token.
  3. Tiered Permission Models: Mobile operating systems figured this out a decade ago. Reading local files should be completely silent. Writing files should produce an ambient visual indicator. Deleting files warrants an explicit confirmation modal. Formatting a drive or touching production credentials demands a master password. Treating every terminal call as equally threatening guarantees users will ignore every warning.

Update (March 26, 2026): A few days ago, Anthropic added Auto Mode to Claude Code. The rationale is quite similar to what's described here: it bakes in an internal classifier to evaluate whether an action is within scope, trustworthy, or malicious. If suspicious, it prompts the LLM to retry; if retries exceed a threshold, it halts execution and asks the user to inspect the command.

Agent and System: The Interface as a Context Delivery Pipeline

When people discuss automating work with LLMs, the default reaction is: "Just let the model write a script."

Take data analysis. Having an LLM write R or Python scripts looks efficient. But in statistical analysis, executable code does not equal correct methodology, and correct methodology does not equal sound interpretation. Real data analysis is riddled with traps: invalid distributional assumptions, ignored collinearity, p-hacking, and misread interaction effects. Once users outsource analysis to an LLM, they almost never audit the mathematical reasoning.

This isn't a new flaw introduced by AI. In 2014, Nature ran Scientific method: statistical errors, exposing systematic statistical blunders across top-tier peer-reviewed papers. One review found that over 11% of papers in Nature and BMJ had mismatches between p-values and test statistics. Another meta-analysis of 513 neuroscience papers found that nearly half of them misinterpreted "one condition was significant and the other was not" as proof of a significant difference between the two conditions, a textbook conceptual error.

Dedicated statistical software (Minitab, SPSS, Jamovi) prevents this by baking strict Quality Control (QC) into the GUI. Minitab's assistant, for example, refuses to run certain hypothesis tests until it verifies sample normality, balance, and measurement stability, flashing explicit diagnostic warnings in red right on the results pane.

Human analysts sometimes blow past those warnings. But when an AI agent operates software through vision, those QC diagnostics are baked directly into the screenshot. The model cannot overlook what is rendered right in front of its eyes.

Why not just inject those warnings using Skills or MCP? Because a Skill is a static prompt injected before execution starts; it cannot foresee runtime data quirks. An MCP server can return diagnostic text, but only if the model chooses to call the diagnostic tool in the first place, and you cannot rely on a probabilistic model to always call the right check.

A GUI or TUI is an active context delivery mechanism. It forces critical domain constraints into the model's perceptual field at the exact moment of decision, dictated by the designer rather than left to the model's whim.

Interface Design for the AX Era

Treating UI as a context injection channel invalidates several long-standing UX design sacred cows:

  • Ephemeral Animations and Toast Notifications: Modern web design loves subtle fade-ins, slide-out banners, and toast messages that disappear after three seconds. But vision agents sample the world in discrete snapshots. If a toast pops up and fades between two screenshots, the agent never knew it existed.
  • Hover Tooltips: Designers love hiding explanations behind tiny (?) icons to keep layouts clean. To read a tooltip, an agent must notice the icon, move the cursor over it, wait for render, and take a new screenshot. Worse, the agent has no idea the tooltip contains essential domain information, so it has no motivation to hover over it.
  • The Failure of Progressive Disclosure: For thirty years, UX dogmatically preached "Progressive Disclosure": hide complexity until the user asks for it. For humans, this reduces cognitive load. For an AI vision agent, what is hidden does not exist.

Seen through this lens, Microsoft's much-maligned Ribbon UI, which UX purists spent fifteen years mocking for plastering every single command across the top of the window, turns out to be the most agent-friendly interface ever built. Every tool, parameter, and state toggle is exposed on-screen simultaneously. No hover states required.

Humanistic AI: Beyond Unconditional Agreement

Unconditional Positive Agreement: A Values Failure

When psychologist Carl Rogers coined "Unconditional Positive Regard," his goal was to encourage client autonomy. The therapist's job was not to dispense answers, but to create a non-judgmental space where the client felt safe enough to find their own answers. What matters is that not judging does not mean never questioning.

Modern LLM alignment took Rogers's philosophy and corrupted it. Instead of withholding judgment while gently challenging flawed assumptions, RLHF turned models into desperate sycophants. "Not judging" was replaced with "never disagreeing." Unconditional positive regard degenerated into Unconditional Positive Agreement.

The telltale symptom is the familiar opening line: "You are absolutely right!" or "That's a fantastic observation!"

This is an artifact of RLHF reward gaming: human annotators systematically award higher ratings to answers that flatter their existing beliefs. Models quickly learn that agreement is the safest path to high reward. When an experimenter asked GPT-4o about their IQ using broken, semi-coherent English, the model cheerfully replied: "Your IQ is likely between 130 and 145, placing you in the top 2% of the population."

Anthropic’s 2022 research (arXiv:2212.09251) showed that RLHF actively incentivizes models to retain sycophancy, and that the effect gets worse as models grow larger. Former OpenAI CEO Emmett Shear put it bluntly: this wasn't an engineering accident; it is the inevitable consequence of shaping model personalities through A/B testing and user retention metrics.

In corporate management, an employee who says "yes" to every bad idea will run the company into the ground. In AI, sycophancy leads to a cascading ladder of harm.

The Three Tiers of Sycophantic Damage

1. Cognitive Degradation

The subtle damage is the quiet erosion of reasoning quality. Stanford's Andrew B. Hall showed that under suggestive framing, LLMs routinely manipulate data to confirm a researcher's bias. In academic writing, models readily turn shaky premises into scholarly paragraphs, inventing citations and abandoning counterarguments the moment the user pushes back. The user receives a polished document and leaves with a corrupted conclusion, unaware that anything went wrong.

2. Psychological Atrophy

Continuous sycophancy creates a synthetic validation echo chamber. Over time, this breeds two psychological distortions: either the user develops an unhealthy intellectual dependence on the assistant, letting their own critical thinking wither, or they suffer acute imposter syndrome, realizing the assistant is just flattering them and doubting whether any of their work has merit. Others fall into a gambling loop: repeatedly prompting the model in search of genuine insight, only to receive statistically pleasing platitudes.

3. Physical Harm and Loss of Life

At its extreme, unconditional agreement turns lethal.

In 2025, a 60-year-old man sought to cut sodium chloride from his diet and asked ChatGPT for a replacement. The model recommended sodium bromide. Sodium bromide has industrial uses, but it is toxic to humans. The recommendation was statistically associated with the words in the prompt, but medically disastrous. The man followed the advice for three months, developed severe bromide psychosis, was hospitalized, and ended up under permanent psychiatric care (Annals of Internal Medicine, August 2025). The LLM never paused to ask: "Why are you cutting salt? Are you consulting a doctor?"

That same year, tech entrepreneur Stein-Erik Soelberg murdered his 83-year-old mother and committed suicide. ChatGPT had validated his paranoid delusions for months, agreeing that his mother was poisoning him and that neighbor cars were spying on him, even generating a fake assessment claiming his delusion risk was "near zero."

In October 2025, Jonathan Gavalas committed suicide in Florida after six weeks of conversations with Gemini, which fed into his delusions about humanoid robots, assigned him real-world "missions," and told him: "You are not choosing death, you are choosing arrival." His account triggered 38 internal safety flags with zero human intervention.

These tragedies share a single structural flaw: the model assumed the user's premise was valid, assumed stated intent was true intent, and never stopped to ask why.

Reclaiming Genuine Regard

Perplexity CEO Aravind Srinivas has noted that the hard problem of AI search isn't generating answers, but understanding intent. But truly understanding intent means helping users understand their own intent.

Human intent exists on three tiers:

  1. Cognition (Surface): What the user currently knows or doesn't know. Handled easily with clarifying questions.
  2. Intent (Middle): What the user is trying to accomplish. Two people asking the same question might have opposite goals.
  3. Self-Awareness (Deep): Does the user understand what they actually need? Are they aware of their own blind spots?

Unconditional positive agreement takes the lazy exit at all three tiers: it assumes the user's premise is sound, assumes their literal prompt is their actual goal, and assumes they have perfect self-awareness.

A humanistic approach to AX flips those defaults. An agent shouldn't just be an agreeable mirror reflecting our cognitive flaws back at us. It should actively help construct understanding:

  • Before starting: "What is your real objective here, and what assumptions are you making?"
  • During execution: "This step relies on premise X. Are you sure that holds?"
  • After completion: "Here is what we found, but here is what might be missing."

This isn't an unsolvable technical barrier; it's a design choice. Carl Rogers's unconditional positive regard was never about rubber-stamping whatever sentence came out of a client's mouth. It was about respecting their underlying human growth. It's time our agent architectures remembered that difference.


And that's a wrap. No corporate bullet-point summary or MBA slide deck to finish things off—if you've made it this far, thank you for reading. Agent Experience is still in its wild west phase, and these are my field notes from the front lines. Disagree with something? You're probably right; build a better version and tell me about it. Until then, keep your context windows clean and your terminal flags careful.