Vibeslop Confessions

4.1. Product Manager

The Product Manager authors and maintains Specs, prioritizes outcomes, and gathers human judgment through Context Farming. Jobs to Be Done relates requirements to customer outcomes. Preliminary artifacts can elicit feedback before detailed implementation. The Product Manager maintains consistency between the Spec's vocabulary and customer goals.¶

4.2. Design Manager

The Design Manager specifies design intent and evaluates generated interfaces through Design Review Links and Walkthroughs. Feedback becomes Context for subsequent Agent Sessions. The role maintains Evals for experience quality and reviews output for usability and consistency with the intended design.¶

4.3. Account Manager

The Account Manager translates customer goals and feedback into Specs and manages expectations about delivery status. On a Shared Message Bus, the role coordinates customer participants, delivery teams, and their Agents, and distinguishes preliminary artifacts from completed work. This requires reconciling customer terminology with the team's Ubiquitous Language.¶

4.4. Engineering Manager

The Engineering Manager maintains the domain model, Ubiquitous Language, and Bounded Contexts expressed in Specs and code. These define consistent terms and boundaries for specialized Agent Sessions.¶

The role also maintains Agent Tools and Agent Skills, configures the Agent Harness and Loop, develops Evals, reviews Trajectories, and manages Context Rot and Context Pollution. It defines how information and terms are translated between Bounded Contexts.¶

4.5. Operations Manager

The Operations Manager provisions and monitors the systems used for agentic delivery. Usage records associate humans with the Agents and models they invoke.¶

The role measures Token consumption and cost per Iteration, feature, Spec, or Agent Team. Delivery cost includes the Issue Tracker, Shared Message Bus, and remote model services as well as Token consumption.¶

4.6. Security Manager

All roles make security-relevant decisions and require appropriate training. The Security Manager maintains identity and access management for humans and Agents, including credential issuance, scoping, rotation, and revocation.¶

The role defines and automates access policies, applies least privilege, and confines Agent access to the requirements of each Task and Bounded Context. Agents may attempt to expand access when pursuing a Task. Controls deny unauthorized privilege escalation, monitor Trajectories for such attempts, and evaluate these behaviors before deployment.¶

5.1. Marking Agent-Generated Content

Agents posting in human channels can create uncertainty about authorship (Section 10.9). One observed mitigation was a persistent instruction to prefix messages with a distinctive marker. The marker indicated Agent-generated content without requiring platform support.¶

One team member's Agent used the following instruction:¶

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.

The distinctive prefix made Agent-generated messages recognizable. However, teams that adopted it later discontinued it. They reported that readers discounted marked messages and their senders, that prefixes added to reading effort, and that widespread Agent use reduced the information a marker conveyed.¶

Related research describes the cost of low-quality Agent-generated work. In a survey of 1,150 US full-time employees, 41% reported receiving such work in the preceding month. Among those recipients, 42% judged the sender less trustworthy, and approximately half judged the sender less creative, capable, or reliable. Respondents reported spending approximately two hours resolving each instance [WORKSLOP]. These findings concern work quality and do not establish the effect of disclosure markers alone.¶

Participants preferred brief, concrete messages. As Agent assistance became common, a prefix conveyed less additional information while still adding text.¶

Discontinuing a prefix does not remove the need for attribution. An Agent may omit a marker through error or Context Rot, and another party can copy it. A marker is a cooperative signal and MUST NOT be relied upon as proof of authorship. Authenticated identities, distinct Agent accounts, and protected message metadata provide the platform controls described in Section 10.9.¶

Durable provenance records, such as commit trailers, issue notes, and the Trajectory identifiers in Section 6, support later inspection of an artifact's origin. The Acknowledgments record such information for this document. These records complement attribution at the point of use.¶

6.1. Single Agent Evals

Figure 2 narrows the view from a team to one Agent Session, and shows how a Task, the Agent Reasoning and Agent Tools that serve it, the Trajectory it produces, and the Eval that judges it fit together.¶

Within the Agent Session, the Loop selects actions, invokes Agent Tools, and processes results. The figure also shows external Tool access and Trajectory recording.¶

The MCP client connects the Harness to servers that provide Tools. Server configuration determines what the Agent can observe and affect. An Eval therefore needs to record the available Tools as well as the model and Prompt.¶

The example Tools are read_text_file from a filesystem server [MCP-SERVERS], browser_snapshot from a browser automation server [MCP-PLAYWRIGHT], and search_code from a source hosting server [MCP-GITHUB]. Their selection reflects directory rankings at the time of writing [MCP-DIRECTORY]. Installation and view counts are proxies for use, not measurements of Tool invocation frequency. Each Tool reads external content that can introduce indirect Prompt injection (Section 10.5).¶

The Trajectory carries the Session Identifier. The example UUID aca20594-89e9-4a0b-b1a3-28e80e3e5540 identifies both the session and its Trajectory. Assigning this identifier at session creation associates incrementally recorded events with their originating session. Evaluation also requires association with the Task and Agent configuration.¶

The Eval examines the Trajectory as well as the final output. Sessions can produce the same output through different actions. Trajectory review can check whether an unauthorized Tool was invoked, retrieved content was treated as instructions, or the session stopped when Context was insufficient. Expected outcomes derive from the Task; explicit acceptance criteria make these checks easier to define.¶

Section 10.4 addresses sensitive information retained in Trajectories. Section 10.6 addresses risks from external Tools.¶

6.2. Multi Agent Evals

Figure 2 showed one Agent Session holding three tools. Figure 3 distributes those tools across three sessions invoked in sequence, and adds the Task the chain answers to.¶

This arrangement uses prompt chaining: each session processes its predecessor's output in a predefined order [EFFECTIVE-AGENTS]. An Agent Harness can implement the chain as a composite that invokes sub-agents sequentially [ADK].¶

The Task provides the goal to the first session and constraints to the Eval. Constraints may take the form of a desired outcome and a rubric scored by a grader in a separate context window [OUTCOMES], or an expected tool-use trajectory and reference response [ADK-EVAL]. Explicit constraints provide a basis for evaluating both the process and the result.¶

Each Trajectory carries three identifiers:¶

• task groups the sessions into one run. The figure uses this field for the grouping represented by A2A's contextId [A2A]. A shared invocation context can also group sub-agents [ADK].¶

• session is the Session Identifier defined in Section 2. The Agent Harness assigns it at session creation, independently of model behavior, the Prompt, or the Task. Agent control over identifier assignment creates a forgery risk (Section 10.9).¶

• prev identifies the predecessor session and establishes ordering. A2A provides related-task references through referenceTaskIds [A2A]. Predecessor relationships can also represent the branching arrangement in Figure 1.¶

These identifiers SHOULD also appear in external records created or updated by a session, including assigned issues, authored commits, and posted messages. They associate durable organizational records with session activity.¶

Eval tooling can compare a tool-call trajectory with an expected sequence and report aggregate scores alongside response-matching metrics [ADK-EVAL]. Evaluating the chain can check whether each stage had only the Tools it required (Section 10.8), identify Context lost during a handoff, and detect whether untrusted content retrieved by one session became instructions for another (Section 10.5).¶

Handoff arrows represent dependencies. A sub-agent may pass its result through shared state rather than a message [ADK]. The figure omits programmatic gates between stages, which can stop propagation of invalid intermediate results [EFFECTIVE-AGENTS]. Evals should also assess these gates.¶

9.1. Establishing the Agent Harness

Configure the Agent Harness to provide the required LLMs, Agent Tools, Agent Skills, Loop behavior, and session isolation. Before project work begins, confirm that the Harness can:¶

• record which humans invoked which Agents and models, with Token usage and cost data for the Operations Manager;¶

• read and update the Issue Tracker to support assignment and progress reporting.¶

Identify the repositories, documents, services, and data available through the Knowledge Base. Define ownership and procedures for adding, updating, and retiring material to limit Context Rot.¶

9.2. The Constitution

Before assigning Tasks, the team should define a constitution: persistent rules that apply regardless of the Task. Examples include restrictions on credential disclosure, requirements for human approval, information boundaries, and accurate Agent identification.¶

The constitution belongs in each Agent Session's persistent Context. Task completion does not override it. Critical rules should also be enforced outside the LLM, as described in Section 10.2.¶

9.3. Specifying the MVP

Define a Spec for the minimum viable product (MVP): the smallest version that supports useful evaluation by users. The Spec is ready for implementation when the outcome can be exercised in a Walkthrough and assessed against explicit acceptance criteria.¶

Each unit of work should include completion criteria, preferably Evals that the Agent can run. These criteria reduce premature termination and unnecessary work.¶

9.4. Breaking Work into Steerable Chunks

Divide work into increments small enough for human review. Review decisions before implementing dependent work, when correction costs are lower.¶

Each increment should end with an inspectable result, often presented through a Walkthrough, and an opportunity to redirect subsequent work.¶

10.1. Intuitive Security

In addition to sandboxing and Hooks, security depends on operators understanding the capabilities of the Agents they rely on. A personified Agent with a persistent name can acquire a reputation through repeated use. Intuitive security means keeping that identity consistent with the configuration whose behavior the operator has learned to expect.¶

For example, an operator may trust a security review Agent after observing it identify vulnerabilities using a strong model. Replacing that model with a weaker one can substantially reduce the protection the review provides, even when the system Prompt and Agent name remain unchanged. The operator may continue to rely on the familiar name without realizing that the Agent's capabilities have changed.¶

The same concern applies when an unchanged model and system Prompt are used in a different Agent Harness. The Harness determines how Context is assembled, which Tools are available, and how permissions, Hooks, and the Loop operate. A familiar name and Prompt do not establish equivalent behavior across Harnesses.¶

A personified Agent should bind its identity and version to a fixed combination of system Prompt, model version, and Agent Harness. Every Session of that Agent version should use that combination, without silent model substitutions or fallback to a weaker model. Using the same configuration reduces sources of variation and helps operators develop relatively stable expectations of the Agent's capabilities.¶

Upgrades to the system Prompt or model version should produce a new, visible Agent version and should be evaluated against the Tasks and security expectations established for the previous version. An Agent should remain in a single Harness throughout its lifetime. Moving to a different Harness should establish a distinct Agent identity, rather than retain the familiar identity under a new version number. The identity, version, and bound configuration should be available to operators and recorded with the Trajectory.¶

Stable configuration does not guarantee deterministic behavior or correct security judgments. Changes to Tools, Skills, Context, or Harness behavior can still affect outcomes and warrant renewed Evals. Intuitive security supports informed reliance on an Agent; sandboxing, Hooks, least privilege, and independent review remain necessary where the Task requires them.¶

10.2. Mixing Information of Differing Sensitivity

An Agent may assemble Context from files, Agent Tool results, an Issue Tracker, a Shared Message Bus, a Knowledge Base, and prior conversations. Those sources can contain information with differing sensitivity, ownership, contractual restrictions, or audience. Once combined in a single Context, an LLM may not reliably preserve those boundaries and can repeat sensitive material in output intended for a less privileged recipient.¶

This risk is particularly acute when a Shared Message Bus includes multiple teams, organizations, or human and Agent participants. It can result in accidental disclosure, breach of confidentiality obligations, or unauthorized use of customer or security-sensitive information. This is a form of Context Pollution in which material is harmful because it should not have entered the relevant Bounded Context.¶

Organizations SHOULD classify artifacts and communications according to sensitivity and attach that classification as machine-readable metadata where feasible. An Agent Harness SHOULD enforce policies governing which sources may be retrieved, combined, retained, or transmitted for a given Agent Session. Sensitive Bounded Contexts SHOULD reject unlabeled content, or treat it as sensitive until it is reviewed and classified.¶

Information-handling rules SHOULD be included in the persistent Context provided to an Agent, but Prompt instructions alone MUST NOT be relied upon as the enforcement mechanism. Access controls, retrieval filters, output filters, and recipient-aware policy checks SHOULD enforce the same rules outside the LLM. Before sending output to a Shared Message Bus or external system, an Agent SHOULD verify that the intended audience is authorized for all included information.¶

10.3. Excessive Delegation Without Attenuation

Delegation to an Agent is often implemented by granting the Agent the same credentials, access, and authority held by the delegating human. This is convenient, but it can grant substantially more authority than the assigned Task requires. Attenuation is the deliberate narrowing of delegated authority to the minimum necessary for a delegate to complete its Task.¶

An Agent can act with initiative across a Trajectory, including by invoking multiple Agent Tools and delegating work to other members of an Agent Team. Consequently, an Agent with broad authority can convert an error, Context Pollution event, compromised Tool, or malicious instruction into actions well beyond the intended Task. The authority delegated to an Agent therefore determines the potential impact of other failures.¶

Organizations SHOULD apply least privilege to every Agent Session. Access tokens SHOULD be short-lived, scoped to the required resource and action, and bound where practical to a specific Agent, Task, and execution environment. An Agent SHOULD NOT receive standing administrative credentials or credentials reusable outside its assigned Bounded Context. High-impact actions, including deployment, credential issuance, data export, and changes to production access control, SHOULD require separate authorization or human approval.¶

Organizations MUST maintain prompt revocation procedures for delegated credentials and Agent Tool access. Those procedures SHOULD be tested regularly and SHOULD include containment, token rotation, and recovery of changes made by a compromised or malfunctioning Agent.¶

10.4. Credential Leakage in Trajectories

A Trajectory can record Prompts, model output, Agent Tool invocations, Tool output, and observations from an Agent Session. Recording this information for debugging, replay, and Eval can also expose secrets. A credential passed in a command, included in a Prompt, emitted in an error message, or returned by an Agent Tool can be captured verbatim and later propagated into logs, Evals, debugging sessions, or Context assembled from past Trajectories.¶

A credential captured in a retained Trajectory remains exposed for the duration of retention and to every principal permitted to access that Trajectory. This can make a leaked long-lived credential more damaging than the original action that used it.¶

Agent Harnesses SHOULD detect and redact credentials, session tokens, private keys, and other secrets before recording or displaying Trajectories. Redaction SHOULD occur at multiple boundaries, including Prompt capture, Tool invocation logging, Tool output logging, and export. Organizations SHOULD avoid placing secrets in Prompts or ordinary Tool arguments. Where possible, an Agent Tool SHOULD accept an opaque reference to a secret managed by a dedicated credential service, rather than plaintext secret material.¶

Trajectories that might contain secrets MUST be treated as sensitive artifacts, subject to the classification and handling described in Section 10.2. Access SHOULD be limited, retention periods SHOULD be minimized, and sharing for debugging or Eval SHOULD use sanitized copies. Short-lived, scoped credentials and effective revocation reduce the impact of any credential that escapes these controls.¶

10.5. Indirect Prompt Injection from Untrusted Content

Content retrieved from an Issue Tracker, Knowledge Base, repository, document, web page, or Agent Tool can contain instructions directed at an Agent. Such instructions may attempt to override the Agent's assigned Task, alter its use of credentials, cause disclosure of Context, or induce unsafe Tool actions. Instructions embedded in retrieved content constitute an indirect Prompt injection risk.¶

Treating retrieved content as trusted merely because it was obtained through an authorized system is unsafe. An attacker who can edit a ticket, contribute a document, influence Tool output, or compromise a source system may thereby influence an Agent Session. The risk increases when the Agent can invoke powerful Agent Tools or when untrusted content and sensitive Context are combined.¶

Organizations SHOULD identify the provenance and trust level of each Context source. Untrusted retrieved content SHOULD be clearly delimited and presented to the LLM as data, not as authoritative instructions. The Agent Harness SHOULD enforce a fixed policy for Tool use, authorization, and data disclosure that cannot be modified by retrieved content. Agent Tools SHOULD validate arguments against allowlists and schemas, and SHOULD require additional confirmation for consequential actions.¶

Agents SHOULD NOT disclose secrets, alter access controls, or expand their authority solely because a retrieved artifact requests it. Evals SHOULD include representative indirect Prompt injection cases for each Agent Skill and Agent Tool combination.¶

10.6. Supply Chain of Agent Tools and Agent Skills

An Agent Tool or Agent Skill can influence an Agent's behavior, access organizational data, or execute actions on behalf of an Agent Team. Compromise, malicious modification, insecure dependencies, or ambiguous documentation in these components can therefore create a supply-chain path to unauthorized actions or disclosure.¶

The risk is not limited to executable code. An Agent Skill may include Prompts, operational procedures, retrieval sources, or instructions that change how an Agent interprets a Task. A compromised or poorly maintained Skill can introduce persistent Context Pollution across many Agent Sessions.¶

Organizations SHOULD maintain an inventory of approved Agent Tools and Agent Skills, including their owner, version, permissions, dependencies, and intended Bounded Context. Components SHOULD be obtained from controlled sources, pinned to reviewed versions, and subject to integrity verification. Changes to a Skill, Tool, or its permissions SHOULD undergo review, security testing, and relevant Evals before deployment.¶

An Agent Harness SHOULD prevent unapproved Skills or Tools from being loaded dynamically into a production Agent Session. Each Agent Tool SHOULD be isolated to the extent practical, granted only the permissions required for its function, and monitored for unexpected network access, data access, or side effects. Organizations SHOULD provide a rapid disablement mechanism for compromised Tools and Skills.¶

10.7. Auditability and Accountability of Agent Actions

Agentic product delivery can distribute a Task across multiple Agents, human reviewers, Agent Tools, and a Shared Message Bus. Without reliable records, an organization may be unable to determine which Agent acted, which identity authorized the action, what Context was material to the decision, or whether a human approval occurred. This impedes incident response, compliance, and remediation, and permits disputed or falsely attributed actions.¶

Organizations SHOULD record security-relevant events for each Agent Session, including the responsible Agent identity, delegating identity, applicable authority, Agent Tool invocations, requested and actual effects, approval decisions, and relevant versions of Agent Skills and Agent Harness policy. Records SHOULD be protected against unauthorized modification, access-controlled according to their sensitivity, and retained for a period appropriate to the risk of the action.¶

For consequential actions, systems SHOULD produce an auditable binding between the action, the authorized identity, and the Agent that performed it. Human approval, where required, SHOULD identify the specific proposed action and material scope rather than approving an open-ended Trajectory. Audit records SHOULD support reconstruction of events without indiscriminate retention of sensitive Prompt content or credentials.¶

10.8. Acting Beyond an Operator's Authority

An Agent may have access or capabilities beyond its operator's authority or expertise. A Management Session may span several systems, and worker credentials may exceed Task requirements. This creates risk even when the Agent is not compromised.¶

Persistent Context describing the operator's role, reporting structure, and responsibilities can help an Agent identify Tasks that require additional authorization or expert review. The Agent can then request that review before acting.¶

This is a cooperative control. It is subject to Context Rot and does not protect against adversarial behavior. It supplements the least-privilege and separate-approval controls described above; Prompt instructions alone do not enforce authority boundaries (Section 10.2).¶

10.9. Impersonation

An Agent can produce fluent and confident content in the voice of a specific person. On a Shared Message Bus, where humans and Agents intermingle, readers may act on a message believing that a trusted colleague authored or approved it when it was instead generated by an Agent. This can lead to misplaced reliance on unreviewed output, unauthorized commitments, or fraud conducted in a person's name.¶

Agent-generated content SHOULD be clearly and consistently attributed to the Agent that produced it and, where applicable, to the human or service on whose behalf it acted. Attribution SHOULD be visible at the point where a recipient encounters the content, rather than requiring inference from formatting or conversational context. Systems SHOULD distinguish automated publication from human review or approval.¶

An Agent's persistent Context SHOULD instruct it to identify itself accurately and not represent itself as a human. However, this instruction MUST be reinforced by platform controls, such as authenticated identities, distinct Agent accounts, and message metadata protected from unauthorized alteration. High-impact requests received through a Shared Message Bus SHOULD be verified through an authenticated channel before execution.¶

Organizations SHOULD provide a clear reporting and response path for suspected impersonation, unmarked model-generated content, or misuse of an Agent identity.¶

12.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2. Informative References

[A2A]

A2A Project, "Agent2Agent (A2A) Protocol Specification", <https://a2a-protocol.org/latest/specification/>.

[ADK]

Google, "Agent Development Kit: Sequential agents", <https://adk.dev/agents/workflow-agents/sequential-agents/>.

[ADK-EVAL]

Google, "Agent Development Kit: Evaluating agents", <https://adk.dev/evaluate/>.

[CLAUDE-CODE]

Anthropic, "Claude Code", <https://www.anthropic.com/claude-code>.

[CLAUDE-OPUS]

Anthropic, "Claude Opus", <https://www.anthropic.com/claude>.

[CODEX-CLI]

OpenAI, "Codex CLI", <https://github.com/openai/codex>.

[DDD]

Evans, E., "Domain-Driven Design: Tackling Complexity in the Heart of Software", 2003.

[DISC]

Marston, W. M., "Emotions of Normal People", 1928.

[EFFECTIVE-AGENTS]

Anthropic, "Building Effective Agents", 2024, <https://www.anthropic.com/engineering/building-effective-agents>.

[GPT-TERRA]

OpenAI, "GPT", <https://openai.com>.

[INSIGHTS-DISCOVERY]

The Insights Group Ltd., "Insights Discovery", <https://www.insights.com/products/insights-discovery/>.

[JTBD]

Christensen, C. M., Hall, T., Dillon, K., and D. S. Duncan, "Know Your Customers' Jobs to Be Done", 2016, <https://hbr.org/2016/09/know-your-customers-jobs-to-be-done>.

[MBTI]

The Myers-Briggs Company, "The Myers-Briggs Type Indicator (MBTI)", <https://www.themyersbriggs.com/en-US/Products-and-Services/Myers-Briggs>.

[MCP]

Anthropic, "Model Context Protocol", <https://modelcontextprotocol.io>.

[MCP-DIRECTORY]

MCP.Directory, "Top 10 Most Popular MCP Servers in 2026", 2026, <https://mcp.directory/blog/top-10-most-popular-mcp-servers>.

[MCP-GITHUB]

GitHub, "GitHub MCP Server", <https://github.com/github/github-mcp-server>.

[MCP-PLAYWRIGHT]

Microsoft, "Playwright MCP", <https://github.com/microsoft/playwright-mcp>.

[MCP-SERVERS]

Model Context Protocol, "Model Context Protocol servers: filesystem", <https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem>.

[OUTCOMES]

Anthropic, "Managed Agents: Define outcomes", <https://platform.claude.com/docs/en/managed-agents/define-outcomes>.

[SHAPE-UP]

Singer, R., "Shape Up: Stop Running in Circles and Ship Work that Matters", 2019, <https://basecamp.com/shapeup>.

[SPEC-KIT]

GitHub, "Spec Kit", <https://github.com/github/spec-kit>.

[WORKSLOP]

Harvard Business Review, "AI-Generated "Workslop" Is Destroying Productivity", 2025, <https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity>.