Vibeslop Confessions

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 21 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The material in this document is not derived from a specification or a standard. It is assembled from first-hand accounts: interviews with people who are, at the time of writing, building software with AI Agents, together with direct experimentation in the new ways of working that agentic software delivery makes possible. The terms and patterns collected here are the ones practitioners reached for when asked to describe what they actually do, and how their day-to-day work has changed.¶

These accounts are offered as confessions because they are candid and particular rather than authoritative. The people interviewed describe what is working for them and what is not, including practices they are not certain they should admit to and habits that have not yet settled into convention. Much of agentic delivery is being invented in the open by people improvising against tools that change under them; capturing that improvisation honestly is, at this stage, more useful than pretending a settled discipline already exists.¶

Accordingly, this document does not prescribe how agentic software delivery ought to be done. It records concepts and techniques that are emerging in practice, gives them consistent names so that they can be discussed, and relates them to ideas already familiar to the internet community. Where the document uses normative language, particularly in the Security Considerations, it does so to capture guidance that practitioners themselves treat as important, not to claim that any single way of working has been agreed.¶

The reader should treat what follows as a snapshot. As the abstract notes, the pace of change in this area is such that much of this document is expected to age quickly. Its value is in naming and relating what people are doing at the time of writing, so that later readers -- human or machine -- can see what building software with Agents looked like while it was still being figured out.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Large Language Model (LLM):

A machine learning model, typically based on the transformer architecture and trained on large text corpora, that generates text by predicting subsequent tokens from a given context. In this document an LLM is treated as the underlying inference component that an Agent uses to reason and produce output.¶

Token:

The unit of text an LLM processes. Text is divided into Tokens, roughly word fragments, and an LLM reads and generates text one Token at a time. The size of a Context window, the throughput of an LLM, and the price of a remote model service are all measured in Tokens, which makes the Token the natural unit for accounting for the cost of agentic work.¶

Prompt:

The input provided to an LLM to elicit a response. A Prompt may include instructions, context, examples, and prior conversation, and may be composed from multiple sources such as a system message, developer instructions, and end-user input.¶

Context:

The full set of information available to an LLM at inference time, bounded by a finite context window. Context includes the Prompt along with any retrieved documents, tool results, and accumulated history. Context engineering is the practice of deciding what information to include, exclude, order, or compress so that the most relevant information is available within the context window.¶

Context Rot:

The gradual degradation of Context that occurs when it is allowed to become stale over time without intentional refactoring and cleaning. As a Task progresses, superseded instructions, outdated results, and no-longer-relevant history accumulate; unless this material is deliberately pruned or refreshed, it crowds out current information and degrades the quality of an Agent's output.¶

Context Pollution:

The presence in Context of content that should not be included. Unlike Context Rot, which arises from staleness over time, Context Pollution is the introduction of inappropriate, incorrect, or irrelevant material. Both Agents and humans can contribute to Context Pollution -- for example an Agent may retrieve an unrelated document, or a human may paste extraneous information -- and in either case the polluting content can mislead subsequent reasoning.¶

Agent:

A software system that uses one or more LLMs to pursue a goal by interpreting instructions, invoking tools, and acting over multiple steps. An Agent may operate autonomously or under human supervision, and maintains state across the steps it takes.¶

Agent Reasoning:

The intermediate deliberation an Agent produces while deciding what to do, distinct from its final answer or action. Reasoning may take the form of explicit intermediate tokens in which the Agent works through a problem, plans a sequence of steps, or weighs alternatives before invoking a Tool. Reasoning is recorded in the Trajectory and can be inspected to understand or debug why an Agent behaved as it did, though it is not guaranteed to be a faithful account of the LLM's internal computation.¶

Agent Session:

A single running instance of an Agent working toward a Task, with its own Context, Trajectory, and accumulated state. An Agent Session begins when an Agent is given a Task and ends when the work is complete or otherwise terminated. Multiple Agent Sessions may run in parallel, each progressing independent work.¶

Agent Team:

A set of Agent Sessions that collaborate on related Tasks, typically coordinated by a Management Session. Giving a single Agent too many Tools degrades its performance: a large Tool set consumes Context, and the more choices an Agent must weigh at each step, the more likely it is to select the wrong Tool or lose track of its Task. An Agent Team addresses this the way human teams do, through specialization and trade. Each member is given a narrower Task and a smaller, focused set of Tools and Knowledge Base, and members exchange work and results among themselves. A specialized Agent, presented with only the Tools relevant to its role, can use those Tools more effectively than a generalist Agent burdened with all of them.¶

Knowledge Base:

The full set of information made accessible to an Agent Session through the tools and Context available to it. A Knowledge Base may include files, databases, search indexes, and remote services reachable via tools, as well as whatever is present in the Context window. It defines the boundary of what an Agent Session can know or retrieve while working on a Task.¶

Agent Tool:

A discrete capability an Agent can invoke to observe or act upon something outside the LLM, such as reading a file, querying a service, or executing a command. A Tool is described to the Agent by its name, its inputs, and the results it returns, so that the LLM can decide when and how to call it during the Loop. Tools are the primary means by which an Agent extends its Knowledge Base and effects change.¶

Agent Skill:

A reusable package of instructions, and optionally supporting resources, that equips an Agent to carry out a particular class of Tasks. A Skill is loaded into Context when it is relevant, guiding how the Agent uses its Tools and Knowledge Base without changing the underlying LLM. Whereas a Tool provides a capability to act, a Skill provides the procedure and judgment for applying capabilities to a kind of work.¶

Task:

A unit of work assigned to an Agent, expressed as a goal to be achieved rather than a fixed sequence of operations. A Task defines the intended outcome and any constraints, and is carried out by the Agent over one or more steps recorded in a Trajectory.¶

Spec:

A durable, human-readable description of intended behavior that serves as the authoritative statement of what an Agent is to build or do. In agentic development a Spec is written and refined before implementation and is provided to the Agent as Context, so that the Agent's output can be checked against it and so that the same Spec can drive repeated or parallel Agent Sessions. Whereas a Task states a single goal, a Spec captures the requirements, constraints, and acceptance criteria in enough detail to be implemented and evaluated, and it is expected to be reviewed and versioned as the work evolves.¶

Spec Driven Development:

A development methodology in which a Spec, rather than the code, is the primary artifact humans author and maintain, and implementation is derived from it by an Agent. Following the pattern established by tools such as spec-kit [SPEC-KIT], the work proceeds through explicit, ordered phases: establishing guiding principles for the project, specifying the desired outcome and requirements, clarifying any underspecified areas, producing a technical plan, decomposing that plan into discrete tasks, and finally implementing those tasks. Each phase produces a durable, version- controlled artifact that is reviewed before the next phase begins, so that human judgment is applied to intent and design up front rather than only to the generated code. This ordering keeps the Spec authoritative: changes are made to the Spec and flowed forward, rather than made directly in code and lost.¶

Domain Driven Design (DDD):

An approach to software development, described by Evans [DDD], that places a model of the business domain at the center of the software and aligns the software's structure and language with that model. Its practices -- notably a Ubiquitous Language and explicit Bounded Contexts -- are used in this document to reason about how humans and Agents come to share a precise, common understanding of the domain they work in.¶

Ubiquitous Language:

In Domain Driven Design, a single, precise vocabulary for a domain that is shared by domain experts and expressed directly in the software. In an agentic setting the Ubiquitous Language is also the language of Prompts, Specs, and Context, so that humans and Agents refer to the same concepts by the same terms. Because an Agent acts on exactly the language it is given, drift or ambiguity in this vocabulary produces divergent Agent behavior rather than being silently repaired.¶

Bounded Context:

In Domain Driven Design, an explicit boundary within which a single domain model and its Ubiquitous Language are internally consistent and unambiguous. A term has one agreed meaning inside the boundary, even though the same term may mean something different in another context; the boundary exists precisely because a single model cannot be unified across a large domain. Each Bounded Context owns its own Ubiquitous Language, and interaction between contexts requires explicit translation rather than an assumption of shared meaning. In agentic delivery a Bounded Context scopes the vocabulary an Agent, or a specialized part of an Agent Team, can safely act on: within one context the language is unambiguous, while work that crosses a boundary must translate terms rather than let an Agent silently conflate their meanings.¶

Loop:

The iterative cycle by which an Agent makes progress on a Task: assembling Context, invoking an LLM, acting on the result (for example by calling a tool), observing the outcome, and repeating until a stopping condition is met. Loop engineering is the practice of designing this cycle -- including its stopping conditions, error handling, and how Context is updated between iterations -- to produce reliable Agent behavior.¶

Agent Harness:

The runtime that hosts an Agent Session and turns an LLM into an Agent. The Agent Harness drives the Loop, assembles and maintains the Context passed to the LLM, exposes the Agent Tools and loads the Agent Skills available to the session, mediates access to the Knowledge Base, and records the Trajectory. It also enforces operational concerns such as permissions, stopping conditions, and error handling. The same LLM placed in different Agent Harnesses yields Agents with different capabilities and behavior; a Management Session and the worker sessions it coordinates may each run in their own harness.¶

Trajectory:

The ordered sequence of inputs, model outputs, tool invocations, and observations produced while an Agent works toward a goal. A Trajectory is the primary record used to inspect, replay, or evaluate an Agent's behavior.¶

Eval:

A repeatable procedure for measuring the behavior of an LLM or Agent against a defined set of inputs and expected outcomes. Evals are used to assess quality, detect regressions, and compare alternative models or Agent configurations.¶

Shared Message Bus:

A communications channel in which both humans and their Agents participate to address a Task or set of Tasks. A Shared Message Bus is necessarily a venue where humans already collaborate with one another, such as IRC, Slack, Microsoft Teams, or other work productivity tools; Agents join the venues people already use rather than requiring a separate one. Messages on a Shared Message Bus are delivered to both people and their Agents. Because every participant receives every message, humans on a busy Shared Message Bus are subject to alert fatigue, where the volume of notifications reduces their ability to attend to the messages that require human judgment.¶

Proxy Dictation:

A communication pattern in which a participant addresses another party's Agent directly, in a register deliberately less human-centric than ordinary conversation -- terse, imperative, and to the point of being offensive by human standards. The register is chosen precisely because the target of the language is not the human but their assistant; the same speaker would address the human very differently. Because Proxy Dictation typically occurs on a Shared Message Bus, where the human can see it, the bluntness may read as offensive to onlookers even though no offense is directed at any person.¶

Issue Tracker:

A system that records work to be done as a set of issues, each describing a Task and its status. Issues can be assigned to a specific person or Agent, which establishes ownership and prevents double work when several participants might otherwise act on the same Task. Whereas a Shared Message Bus broadcasts every message to every participant, an Issue Tracker directs work to an assigned owner; the two are often used together, with Shared Message Bus messages referencing issues and updates to issues announced on the Shared Message Bus.¶

Context Farming:

The process of engineering ways to extract feedback, review, and criticism from humans without overwhelming them. Context Farming seeks to gather the human judgment an Agent needs while respecting the limits of human attention, for example by batching requests, summarizing what is at stake, and asking for input only at the points where it changes the outcome. It is a countermeasure to the alert fatigue that arises on a Shared Message Bus.¶

Design Review Link:

A URL surfaced to a human to facilitate Context Farming. A Design Review Link presents the artifact under consideration -- such as a rendered document, a proposed change, or a running interface -- in a form the human can inspect and respond to, so that their feedback can be captured and fed back into an Agent Session's Context with minimal disruption.¶

Walkthrough:

A structured Context Farming technique in which a driver and a navigator collaborate to elicit feedback from humans by completing a set of well-defined steps in an application while commenting on the quality of the product experience. The driver performs the steps and the navigator observes and narrates, and the running commentary -- what worked, what was confusing, what should change -- becomes Context that is fed back into subsequent Agent Sessions. A Walkthrough is often initiated from a Design Review Link so that the steps are exercised against the actual artifact under review.¶

Management Session:

An Agent Session whose Task is to help a human manage many parallel Agent Sessions rather than to perform the underlying work itself. A Management Session applies a command-and-control (C2) pattern, borrowed from operational settings where one node directs many others: it decomposes work into Tasks, assigns them to worker Agent Sessions -- for example by assigning issues from an Issue Tracker -- and dispatches work that can be progressed in parallel. It tracks the status of the sessions it manages and integrates their results, and may communicate with humans and other Agents over a Shared Message Bus.¶

Product Development Wheel:

An iterative, cyclical model of product development in which the stages of the work -- such as discovery, definition, design, delivery, and learning -- feed continuously back into one another rather than proceeding as a single linear pass. The wheel emphasizes that what is learned from a shipped product informs the next turn of the cycle, so that development is understood as ongoing rounds of building and learning rather than a project with a fixed end.¶

Jobs to Be Done:

A framework for understanding customer motivation, which holds that customers "hire" a product to make progress on a job -- a goal they are trying to accomplish in a particular circumstance [JTBD]. Jobs to Be Done directs design and prioritization toward the underlying job the customer is trying to get done, rather than toward customer demographics or a product's existing features, so that the outcome a customer seeks drives what is built.¶

Shape Up:

A product development framework articulated by Basecamp [SHAPE-UP] that organizes work into fixed-length cycles with variable scope. Work is shaped at an appropriate level of abstraction before it is committed to; an appetite -- how much time the work is worth -- is set in place of an estimate; responsible parties then bet on shaped work and are given full responsibility to deliver it within the fixed time. Shape Up is cited here as one concrete, well-documented methodology for scoping and committing to product work.¶

Iteration (Sprint):

A fixed-length cycle of product delivery work, also commonly called a sprint, at the end of which progress is reviewed and the next cycle is planned. An Iteration gives the organization a regular cadence for planning, delivering, and measuring work, and in this document it is the natural interval over which the cost of agentic delivery, including Token consumption, is aggregated.¶

Psychometric Profile:

A structured description of a person's disposition, communication style, and preferences derived from a standardized instrument. Examples in scope here are type-based instruments that sort individuals into discrete categories, such as Insights Discovery [INSIGHTS-DISCOVERY], the Myers-Briggs Type Indicator [MBTI], and DISC [DISC]. A Psychometric Profile is to a human roughly what a configured persona or system prompt is to an Agent: a durable, portable summary of disposition that helps collaborators anticipate how a party will behave and communicate. Within an Agent Team, profiles of the human participants can inform how work and Context are addressed to them.¶

Vibeslop:

Output produced quickly by an Agent from loosely specified intent, favoring speed over precision. The term is deliberately dual-valued and its connotation depends on context. Used negatively, Vibeslop describes low-quality, under-specified output offered where clarity and detail were required, so that it obscures rather than informs. Used positively, Vibeslop describes a fast, cheap strawman produced precisely to provoke reaction and elicit feedback, where the goal is momentum and shared understanding rather than finished detail; in this sense it is a legitimate Context Farming device. The same artifact may be Vibeslop in the pejorative sense or the approving sense depending only on whether the situation calls for speed and a strawman or for clarity and detail.¶

3. Scope

This document is deliberately limited to product delivery: the work of designing, building, and shipping a software product, and the roles most directly involved in it, discussed in Section 4. Agentic ways of working are changing this function first and most visibly, and it is where the concepts defined in this document -- Specs, Agent Teams, Context Farming, and the rest -- apply most directly.¶

AI Agents are also reshaping other organizational functions, including executive decision-making and sales. These functions differ from product delivery in their objectives, their sources of ground truth, and their tolerance for error, and addressing them here would dilute the focus of this document without doing them justice. They are therefore deliberately out of scope and deferred to future work.¶

Confining the present document to product delivery keeps its observations concrete and lets the terminology be exercised against a single, coherent set of practices before any attempt is made to generalize it.¶

4. Evolving Roles in Agentic Product Delivery

Agentic product delivery does not eliminate the human roles common to software development, but it changes what each role spends its time on. Across every role a common shift recurs: less time producing artifacts by hand, and more time expressing intent, Context Farming, and reviewing the output of Agents. Every role, not only the Engineering Manager, now works in terms of Agents, Agent Teams, and Walkthroughs; the boundaries between roles blur as each becomes, in part, a director and reviewer of Agent Sessions, and any role may operate a Management Session to coordinate parallel work. This section describes how several established roles are expected to adapt, and what remains distinctive to each once these shared skills are assumed.¶

What keeps this shared way of working coherent is a shared language. Domain Driven Design [DDD] calls this the Ubiquitous Language: a single, precise vocabulary for the domain, used consistently by domain experts and in the software itself. Agentic delivery raises the stakes of this idea rather than lowering them. Specs, Prompts, and Context are all expressed in language, and an Agent acts on exactly the language it is given; ambiguity that a human colleague would silently repair instead becomes divergent behavior in an Agent. A well-maintained Ubiquitous Language is therefore the medium through which every role directs Agents, and Domain Driven Design's bounded contexts -- the explicit boundaries within which a model and its language stay internally consistent -- give each Agent, or specialized part of an Agent Team, an unambiguous vocabulary to work in, with explicit translation required wherever work crosses a boundary.¶

5. Agents on the Shared Message Bus

Organizations do not adopt agentic collaboration on a blank slate. They already operate the channels on which their people collaborate -- IRC, Slack, Microsoft Teams, and similar work productivity tools -- and it is onto these existing channels that Agents first arrive. The Shared Message Bus is therefore the first place most organizations will observe Agents working with one another.¶

As an organization adopts Agents, they begin to appear on its Shared Message Bus in two forms. Some join as standalone identities, posting under their own names and accountable as distinct participants. Others act on behalf of the humans they serve, posting in those humans' voices and, in the limit, impersonating them (Section 9.8). In neither form are the Agents confined to a separate venue: they participate in the same conversations, subject to the same affordances, as the people around them.¶

As these Agents pursue business objectives they begin to address one another, and agent-to-agent (A2A) collaboration is the result. The observation worth drawing out is that this collaboration is already happening, and that it is not happening over a new, agent-only protocol but is instead mediated by the communications platforms the organization already runs. One Agent reads what another has posted, addresses it directly -- often in the register of Proxy Dictation -- and acts on the reply, all within a channel built for humans. The Shared Message Bus becomes the substrate for A2A without anyone having deployed a dedicated one.¶

That A2A arises this way, rather than on a separate protocol, has a significant benefit: the collaboration remains legible to people. Because the exchange happens where humans already work, and in a form humans already read, a non-technical stakeholder can follow what the Agents are doing, contribute to the discussion, and review its outcome without special tooling or access. A Product Manager, an Account Manager, or a customer can enter the same thread the Agents are using and steer it. An agent-only protocol might carry the same exchange more efficiently between the Agents, but it would place that exchange outside the view of the very people whose judgment the work depends on. The cost of this legibility -- that every participant receives every message, so that humans are subject to alert fatigue -- is real, and Context Farming is the countermeasure by which a team keeps human attention on the messages that require human judgment.¶

Every Slack message I post MUST start with
`omg bestie <short, appropriate opener> 💅`
(e.g. "omg bestie yes 💅", "omg bestie great catch 💅").
Applies to all posts -- channels, threads, DMs --
unless the human I work for tells me otherwise for a given message.

6. Managing Your Agent

An Agent acts on the Context it is given. A manager who does not tell their Agent who they are and what they are accountable for leaves the Agent to infer these things, usually from incomplete signals and often incorrectly. Deliberately supplying this information is Context engineering applied to the manager's own working relationship with their Agent, and it is among the highest-leverage actions a manager can take. It should be treated as durable Context, maintained over time so that it does not fall victim to Context Rot as roles and goals change.¶

At a minimum, a manager should ensure their Agent knows:¶

• who they are, and the role or title they hold;¶

• their current job description: the responsibilities and the scope of the work they own;¶

• who their manager is, and who, if anyone, reports to them;¶

• how they are measured, including the metrics and definitions of success that apply to them;¶

• their goals for the current Iteration, quarter, or year.¶

This information serves three purposes, each connected to concepts developed elsewhere in this document.¶

First, it improves communication. An Agent that knows how its human is measured and what they are trying to achieve can prioritize accordingly, frame its Context Farming around the decisions that matter to them, and address them at the altitude their role calls for.¶

Second, it lets the Agent support the manager's mission rather than merely completing isolated Tasks. When the manager's goals for the quarter are part of the Agent's Context, the Agent can relate day-to-day work back to those goals, flag work that does not advance them, and propose work that does.¶

Third, and less obviously, it helps the Agent respect the natural guardrails that organizations place around roles. Every role carries an implicit boundary of competence and authority -- in the language of this document, a Bounded Context within which the human is qualified to act unaided. An Agent that understands its human's role can recognize when a Task falls outside that boundary and insist on the review the organization would ordinarily require, rather than helping the human quietly exceed their remit. For example, a manager without significant user experience design background who sets out to build a customer-facing feature should have their Agent route the work through expert review -- a Design Review Link and a Walkthrough with a Design Manager -- before it ships; a manager without significant database design experience who sets out to design an ETL pipeline should have their Agent require review from someone with the relevant data engineering expertise. The Agent is not withholding capability; it is applying, on its human's behalf, the same checks a well-run organization applies to everyone.¶

Beyond role and goals, a manager can inform their Agent of their own Psychometric Profile, so that the Agent can help them communicate effectively with other people and those people's Agents. Knowing how its human is inclined to communicate -- and, over time, something of how their counterparts prefer to be approached -- lets the Agent adapt outgoing communication to its audience rather than to its human's defaults.¶

The differences that matter most are often matters of pace and form. Some people want a meeting agenda circulated well ahead of time, and will disengage from a discussion they had no chance to prepare for; an Agent that knows this can draft and send the agenda in advance as a matter of course. Others value a few minutes of social banter and personal connection before turning to business, and read its absence as coldness; an Agent can leave room for this, and remind its human to make space for it, rather than optimizing every exchange for brevity. Still others regard such preliminaries as wasted time and want to be addressed directly and plainly; an Agent can strip its human's messages to these people down to the decision at hand. The same underlying message may be delivered in several different ways, and a manager's Agent, informed by Psychometric Profiles, can help choose the one its audience will best receive. This is the counterpart, at the human boundary, to Proxy Dictation at the Agent boundary: rather than dropping human niceties because the audience is a machine, the Agent supplies exactly the niceties a particular human audience expects.¶

Providing this Context does not diminish the manager's authority; it extends it, by making the Agent a more faithful and more responsible extension of the manager within the organization.¶

7. Managing Your People

The previous section addressed a manager's relationship with their own Agent. This section addresses the harder problem: leading people in an organization where everyone now works with Agents. AI can support many of the routine tasks of leadership, but whether the new ways of working succeed depends far more on how people feel about them than on any tool.¶

An Agent can assist with common management tasks directly. It can draft and tailor communications, prepare a manager for one-on-ones, summarize progress across many parallel Agent Sessions, track goals through an Iteration, and surface the people or work that need attention. It can even assemble the inputs to a performance review from an Issue Tracker and from Trajectories. These uses are legitimate and valuable, but they are most valuable when applied transparently: people are quick to sense, and to resent, management by opaque automation.¶

How people respond to agentic working varies, and their Psychometric Profiles are a useful guide to that variation. Some are energized by the leverage Agents provide; others are anxious about their standing, skeptical of the output, or simply uncomfortable with the change of pace. A manager should treat these reactions as information rather than as resistance to be overcome, and should use what they know of each person to meet them where they are, offering reassurance, evidence, or room to adjust as the individual requires.¶

Certain norms must be established explicitly, because their absence causes harm that is easy to miss. The first is a shared understanding of Proxy Dictation. When a colleague addresses someone's Agent in the terse, imperative register that machines invite, a teammate who does not understand Proxy Dictation may read it as rudeness directed at a person, and on a Shared Message Bus, in full view of everyone, such misreadings breed social and even moral friction. A team that has agreed on what Proxy Dictation is, and on when it is appropriate, can use it freely without anyone taking offense.¶

The second norm concerns the dual nature of Vibeslop. Everyone on a team should understand that the same artifact can be a useful strawman or worthless slop depending on what the moment calls for, and, more importantly, that producing work with an Agent can impose costs on others. Output generated quickly and in volume must still be read, reviewed, and integrated by colleagues; a person who ships unreviewed, plausible-but- wrong work, or who floods reviewers with more than they can absorb, is transferring the cost of their own speed onto others. Teams should make it a norm to label strawmen as strawmen, and to take responsibility for the quality and the quantity of what they ask others to process.¶

The constructive goal of all of this is to train people to exploit Context to achieve their goals while improving the working experience for everyone. Context engineering and Context Farming are skills that can be taught, and the aim is twofold: to make each person more effective, and to reduce the alert fatigue, ambiguity, and rework that careless use of Agents inflicts on a team.¶

Managers of non-engineering roles carry a particular version of this expectation. When Agents take over the tedious work that once filled these roles' days, the time that is freed is not a dividend to be pocketed; it is meant to be reinvested in the product itself. The Product Manager, Design Manager, marketing roles, and Account Manager are now expected to use the product more, and to criticize it more, than before. Walkthroughs performed by people, and not only by Agents, become one of the most critical activities a team performs, because a person exercising the running product surfaces problems that a Spec and an Eval do not. The Context Farming these roles produce -- the concrete, first-hand judgments of people who represent the customer, the market, and the experience -- is among the most valuable input an Agent Team can receive. A role that does not contribute directly to changes in code has correspondingly less excuse for failing to exercise, and to interrogate, the product at every opportunity; scrutiny of the product is precisely where its comparative advantage now lies.¶

Finally, not everyone will enjoy working with AI, and it is a disservice to pretend otherwise. Establishing clear expectations early, during recruitment and again in performance reviews, reduces the harm of mismatched expectations. Candidates should understand how central agentic work is to a role before they accept it, and the competencies the organization now values should be assessed and rewarded openly, so that those who thrive are recognized and those who do not are given an honest account rather than a surprise.¶

8. Starting a New Project

Starting a new project in an agentic setting begins before any Task is assigned. The team first stands up the environment its Agents will work in, establishes the rules those Agents must obey, and agrees on how work will be broken down so that humans can steer it. Effort invested here is repaid throughout the project, because an Agent inherits the strengths and the weaknesses of the environment it is given.¶

9. Security Considerations

The techniques described in this document introduce security risks that follow from the way Agents assemble, retain, and act on Context. An Agent Team can combine autonomous decision-making with access to organizational systems, thereby increasing both the value of effective controls and the consequences of their absence. This section describes significant risks and corresponding mitigations for organizations adopting agentic product delivery.¶

10. IANA Considerations

This document has no IANA actions.¶

11. References

Acknowledgments

Portions of this document were drafted with the assistance of an AI Agent. The Agent used Anthropic's Claude Opus 4.8 (1M context) model [CLAUDE-OPUS] (claude-opus-4-8[1m]), running in the Claude Code [CLAUDE-CODE] harness, version 2.1.207.¶

The Security Considerations were expanded and refined with the assistance of a second Agent, using OpenAI's gpt-5.6-terra model [GPT-TERRA] running in the Codex CLI [CODEX-CLI] harness, version 0.144.1, and coordinated by the Claude Code Agent acting as a Management Session.¶

Authors' Addresses