CodeRabbit - How Can You Trust Your AI Agents

CodeRabbit - How Can You Trust Your AI Agents? ![rw-book-cover](https://img.youtube.com/vi/y_2vGKvhzaw/maxresdefault.jpg) 🔗 **Source:** [CodeRabbit - How Can You Trust Your AI Agents?](https://www.youtube.com/watch?v=y_2vGKvhzaw) > [!note]+ Document Notes > tags: [ai-agent-trust, agentic-explainability, code-review, ai-governance, engineering-leadership] > author: [MISSING] > source: LeadDev > reference: https://www.youtube.com/watch?v=y_2vGKvhzaw > date created: 2026-07-14 00:00 > > # 🏷️ Title: CodeRabbit - How can you trust your AI agents? >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [LeadDev](https://leaddev.com/) - [CodeRabbit](https://www.coderabbit.ai/) - [LinearB / Dev Interrupted](https://linearb.io/) - [Awaze](https://www.awaze.com/) ## 📝 Summary - A LeadDev panel (in partnership with CodeRabbit) asks whether "trust" is even the right word for how organizations relate to coding agents, then works through what earns that trust in practice. - Panelists: Claire Reckless (Senior Engineering Manager, Awaze), Andrew (go-to-market engineer, LinearB; host of Dev Interrupted), and Priyanka (Staff Product Manager, CodeRabbit). Moderated by Jenn Wiggins (LeadDev). - Core argument: trust isn't a property of the agent alone — it's a property of the system (permissions, observability, audit trails, human checkpoints) the agent operates inside. - A live poll found 64% of attendees had, in the past week, lost track of what an AI agent was doing and why — used as the framing problem for the whole session. - Key mechanisms discussed: least-privilege/least-agency permissioning for sub-agents, progressive disclosure of agent reasoning before/during/after code generation, exportable and immutable audit artifacts, and treating PR review load as a first-class metric. - Risk flagged repeatedly: rising PR volume and bot-generated review comments increase cognitive load to the point that developers "rubber stamp" work instead of reviewing it — which defeats the purpose of human oversight. - Organizational point: agentic maturity is uneven even within a single company or a single manager's teams; culture and psychological safety to report failure matter as much as tooling. - Bottom line: trust is earned per-session, continuously, not proven once — agents are probabilistic, so past good behavior doesn't guarantee future good behavior, and 100% trust in a workflow generally means it should have been plain automation instead. ## 📖 Main Content The panel opens by interrogating its own premise: is "trust" — a fundamentally human concept — even the right word to apply to software agents? Priyanka argues the concept has shifted because agents no longer just chat; they act with delegated authority (merging code, issuing refunds, answering customers) under a human's name, so the stakes of being wrong have risen along with the "humanization" of the relationship — she compares it to an intern being trusted with progressively more responsibility. Andrew agrees trust is real and earned, not bought or built outright, but reframes where it lives: not in the agent, not in the human operator, but in the surrounding system — the golden path of tooling, permissions, and observability that both sides operate within. Claire grounds this in practice from her own teams at Awaze: guardrails (restricted permissions, narrowed scope) and human checkpoints at defined stages are what let a team feel confident handing work to an agent. The discussion moves to least privilege becoming "least agency" for agentic systems (a term introduced by an audience member, Kieran) — the added wrinkle being that agents are non-deterministic, so a permission model that was safe last week isn't guaranteed to still be safe today. Claire describes a real practice: breaking a workflow into sub-agents with fine-grained read-only vs. read/write permissions, defined and shared as configuration rather than left to individual developers' "prompt magic," so the same guardrails apply org-wide and get revisited over time. Andrew adds that observability of what an agent actually touches (especially customer/employee data) matters more than a one-time permission audit, because probabilistic behavior means problems can "float under your nose" without continuous visibility. A substantial segment covers where humans fit into an agent-heavy SDLC. Priyanka lays out a three-stage model for earning trust across the software lifecycle: (1) before code is written — the agent should expose its plan (which classes/services it will touch, tests it will write, alternatives it considered and discarded) so a one-line intent like "integrate my tool with Salesforce" doesn't turn into a black box; (2) during code generation — progressive disclosure of which functions were invoked, which APIs were called, what tests were written; (3) after the code is written, during review — where she identifies the sharpest current problem: stacking multiple review bots onto a PR increases cognitive load so much that developers stop reading and start rubber-stamping, which defeats the purpose of review for both the original author and any downstream reviewer. Her proposed fix is for the agent to explain itself at a level the developer would recognize as "what I would have written," and to produce an exportable, immutable artifact that survives past the PR for post-incident debugging (she notes the common failure mode of an agent doing X, Y, and Z when only asked for X, with no record of why). Andrew connects this to how the Git PR itself has changed character — from a "buddy-to-buddy" human review exchange into something closer to a highway lane or a receipt, given the sheer volume of agent-generated code now flowing through it. He argues this shift means PR flow metrics (open count, time-to-review, cycle time, rework rate) become proxies for whether the org's process can actually absorb agentic velocity, and that raw token/spend metrics are a trap — the real question is whether end-user experience changed, not whether "productivity" numbers moved. On auditing specifically, Andrew recommends keeping transcripts, tracking model/tool/MCP-server usage and frequency, and using infrastructure like the Agent Gateway (a Linux Foundation agentic-AI project) to aggregate sessions and logs at scale — arguing that, like the PR itself, git tooling needs to evolve to hold agent sessions natively. Priyanka extends this with an audience-first design principle: know who consumes the audit artifact (a solutions engineer needs a short narrative; a backend engineer debugging an incident needs full tool-call/branch detail) and distinguish synchronous explainability (live, while a human watches) from asynchronous explainability (post-hoc, exportable, immutable, calibrated to a reader with zero background — neither a 250-page dump nor a one-line summary). Asked for a concrete example of a nearly-100%-trusted agent, none of the panelists can name one — Andrew argues there's no "trust dashboard," and that trust is earned by pairing engineering skill with domain expertise early in a build, not by a single number. Claire adds that if you actually reach 100% trust in a task, that task probably should have just been deterministic automation, not an agent. The panel closes on organizational maturity: agentic adoption is highly uneven even within one manager's own teams (Claire runs two teams at very different stages), and Andrew frames the real management challenge as turning isolated "1000x engineers" into a broadly leveled-up "10x everyone." Priyanka frames the gap as equally cultural and technological — adoption requires visible proof of value, not mandates, and products win long-term by making the explainability layer (increasingly "AI explaining AI explaining AI," bottoming out at a human) the actual product. The session ends with a call to normalize sharing agent failures the way the industry once talked about "fail fast," since right now almost no one is publicly discussing what's going wrong. ## 🗒️ Notes The transcript retrieved from vidIQ did not include timestamp markers, so segments below are organized by topic rather than by timecode (no timestamped links are included, to avoid fabricating time offsets). #### Framing: is "trust" the right word? - Priyanka: agents have "humanized" because they now act with delegated authority (production access, refunds, customer answers), not just chat. - Andrew: trust is externalized and earned, not bought; it applies to systems and code just as much as to people. - Claire: guardrails and human checkpoints are what let teams build confidence, not blind faith in the model. #### Poll result used as framing device - 64% of live attendees said yes, they'd lost track of what an agent was doing and why in the last week; 28% said no; 8% hadn't thought about it. #### Least privilege becomes "least agency" - Audience question (Kieran, London) introduces the term "least agency" as the agentic-era evolution of least-privilege IAM, given non-deterministic behavior. - Claire: sub-agents get fine-grained read-only vs. read/write permissions defined as shared configuration, not left to individual prompt engineering; permissions are revisited continuously. - Andrew: continuous observability of data access matters more than a point-in-time permission review, because probabilistic systems can drift under the radar. #### Three-stage model for earning trust across the SDLC (Priyanka) - Before coding: agent shows its plan — classes/services touched, tests to be written, blind spots, alternatives considered and discarded — before the human commits to a prompt. - During coding: progressive disclosure of function calls, API calls, and tests written as the agent works. - After coding (review): the core current failure mode — stacked review bots increase cognitive load until developers "rubber stamp" rather than read; fix is agent-generated explanations calibrated to feel like something the developer would have written themselves, plus an exportable, immutable artifact for post-incident debugging. #### The PR as bottleneck and metric - Andrew: the PR has shifted from a human-to-human review exchange into something more like a receipt or a highway lane, given the volume of agent-authored code. - Recommended metrics: PR open count, cycle time, time-to-review, rework/rejection rate — track these over raw token/spend numbers. - Caution from Jenn Wiggins: watch for orgs claiming productivity gains via "crazy metrics" (e.g., unexplained 60% productivity claims) without any visible change in end-user experience — that's a red flag masking token-maxing as value. #### Auditability and explainability - Andrew: keep transcripts, track model/tool/MCP-server usage and frequency; use aggregation infrastructure like Agent Gateway (Linux Foundation agentic-AI project) to centralize sessions and logs; git tooling itself needs to evolve to hold agent sessions natively. - Priyanka: design the audit artifact around a specific audience and job-to-be-done (solutions engineer vs. backend engineer debugging an incident need very different depth); distinguish synchronous (live, human watching) from asynchronous (exportable, immutable, backgroundless-reader-calibrated) explainability. #### Can any agent reach ~100% trust? - No panelist could name one. Andrew: there's no "trust dashboard"; trust is earned by pairing engineering and domain expertise early, not measured as a single score. - Claire: 100% trust in a task is a signal the task should have been deterministic automation, not an agent. #### Organizational and cultural maturity - Claire: her two managed teams are at very different points in agentic adoption — starting small (research, ticket refinement) builds confidence before expanding scope. - Andrew: the real leveling challenge is turning isolated "1000x engineers" into a broadly capable "10x everyone," since individual fluency with agents varies enormously even within one org. - Priyanka: adoption is as much cultural as technological — people need visible proof of value, and psychological safety to say "we adopted the wrong tool, can we move on?" - Closing audience reference: Amy Edmondson's *Right Kind of Wrong* (intelligent failure) offered as a framework for treating agent failures as learning moments rather than something to hide. ## 📚 References - [LeadDev](https://leaddev.com/) — event host and channel - [CodeRabbit](https://www.coderabbit.ai/) — panel partner, Priyanka's employer - [LinearB](https://linearb.io/) / Dev Interrupted podcast — Andrew's employer and podcast - [Awaze](https://www.awaze.com/) — Claire's employer (UK holiday-lettings company) - Amy Edmondson, *Right Kind of Wrong* — referenced by an audience member re: intelligent failure - Agent Gateway — Linux Foundation agentic-AI infrastructure project mentioned by Andrew for session/log aggregation ## 🗣️ Paraphrase - Trust in coding agents isn't a trait you verify once and bank — it's continuously earned, session by session, because the underlying models are probabilistic and can behave differently even under identical-looking conditions. The panel's consistent answer to "how do you trust an agent" is: you don't, exactly — you build a system around it (scoped permissions, staged disclosure of its reasoning, exportable audit trails, and real human checkpoints) that lets you catch and correct it quickly when it inevitably drifts. - The most urgent practical problem right now isn't agents making mistakes — it's that the flood of agent-generated code and bot review comments has overwhelmed human reviewers to the point where they stop actually reviewing. Fixing that requires agents that explain themselves at the developer's level of understanding, not agents that generate more text for humans to skim past. ## 📰 Newsletter **Can you actually trust your coding agent — or have you just stopped checking?** A LeadDev panel with CodeRabbit, LinearB, and Awaze tackled a question every engineering org is quietly avoiding: when an agent merges code, answers a customer, or touches production under your name, what does "trust" even mean? The standout stat: 64% of live attendees admitted that in just the past week, they'd lost track of what their AI agent was doing and why. The panel's answer wasn't a tool recommendation — it was a systems argument. Trust doesn't live in the model; it lives in the permissions you scope down to "least agency," the checkpoints you keep human, and the audit trail you can actually read after something goes sideways. The sharpest warning: stacked code-review bots are quietly training developers to rubber-stamp PRs instead of reading them, which defeats the entire point of review. And the tell that a workflow doesn't need an agent at all? If you'd trust it at 100%, it should probably just be automation. Worth sharing with anyone shipping agentic tooling into a codebase this quarter. ## ✅ Action Items #### DevRel - Developer advocacy: share internal case studies of agent guardrail failures and fixes the way this panel modeled — normalize discussing "what went wrong," not just wins. - Education: build a short internal workshop on writing agent permission scopes ("least agency") for sub-agent pipelines. - Developer experience: prototype a pre-coding "plan disclosure" step (classes touched, tests planned, alternatives discarded) before an agent starts writing code. #### OSPO Not applicable to this source — the panel discusses internal engineering-org agent governance, not open-source project stewardship or license/security compliance functions. #### Community - Maintainers/teams: institute a lightweight per-session review of agent audit logs after any agent-authored PR that touches production paths. - Cross-team: run a "confidence audit" comparing how differently two teams under the same manager use agents, and close the gap deliberately (per Claire and Andrew's "10x everyone" point). #### WordPress Not applicable to this source — the video contains no WordPress-specific content; it is a general engineering-leadership panel about agentic coding trust across any codebase. #### The WPCC Not applicable to this source — no WordPress Community Collective or governance content appears in the transcript. ### FAIR Not applicable to this source — no FAIR-data, provenance, or governance-artifact content appears in the transcript; the closest analog (audit trails, permission scopes) is covered under Main Content and Notes instead. ## 🧪 Hypotheses - Teams that scope agent permissions into fine-grained, shared "least agency" sub-agent configurations will see fewer unexpected production-touching actions than teams relying on ad hoc per-developer prompting. - Orgs that require agents to disclose a pre-execution plan (files/services touched, tests planned) will show measurably lower post-merge revert/rework rates than orgs that only review after code is generated. - PR cycle time and time-to-review will correlate more strongly with reviewer trust/confidence in agent output than raw lines-of-code or token-spend metrics do. - Organizations that treat agent audit logs as exportable, immutable, per-session artifacts will resolve agent-related incidents faster than those relying on ephemeral chat transcripts alone. - Teams with explicit psychological safety to report "the agent did something we didn't expect" will iterate toward higher agent trust faster than teams where failures go unreported. ### 📊 Methodology - Compare incident resolution time in orgs with exportable per-session agent audit trails vs. orgs without, controlled for team size and codebase complexity. - A/B test agent workflows with and without a mandatory pre-execution plan-disclosure step, measuring downstream PR rework/revert rate. - Survey developers on trust confidence before and after introducing fine-grained sub-agent permission scoping. - Track PR cycle time, time-to-review, and rework rate across teams at different stages of agentic adoption within the same organization (as Claire's two teams illustrate). ### ❓ Questions - What would a genuine "trust dashboard" for an agent look like, if per-session variability makes aggregate metrics misleading (as Andrew argues)? - How do you retrofit audit-trail requirements onto git/PR tooling that wasn't designed to hold agent session data natively? - At what point does "least agency" permissioning become so granular that it reintroduces the friction agents were meant to remove? - How should audit artifact depth be calibrated differently for a solutions engineer vs. a backend engineer debugging a production incident, in a way that's maintainable at scale? ### 🔮 Future Research - Formal frameworks for "least agency" as a distinct discipline from least-privilege IAM, given non-deterministic actors. - Standardized formats for exportable, immutable agent-session audit artifacts (the panel gestures at Agent Gateway but treats the space as still forming). - Longitudinal study of PR review quality (not just volume) as agent-authored code share increases, to test whether "rubber stamping" is measurably rising. - Org-level case studies distinguishing genuine productivity gain from token-maxing dressed up as a productivity metric. ### 💡 Implications - Practice: engineering teams should treat agent permission scoping and audit-trail export as first-class SDLC infrastructure, not an afterthought bolted onto existing PR tooling. - Policy: organizations adopting agents in regulated contexts (e.g., fintech, as one attendee noted) need explicit low-risk starting scopes (e.g., pulling error logs, proposing hypotheses) before expanding to higher-stakes actions. - Security: fine-grained, continuously revisited sub-agent permissions ("least agency") reduce blast radius from a single misbehaving agent session. - Education: developers and managers need explicit training in reading/interpreting agent-generated explanations, not just in prompting agents. - Funding: leadership pressure for "productivity" metrics risks incentivizing token-maxing over genuine end-user-facing improvement unless tied explicitly to customer outcomes. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade approx. 9-10 (Flesch Reading Ease approx. mid-50s) — conversational spoken register with moderate technical vocabulary (IAM, MCP, SDLC, DORA-adjacent terms), long run-on sentences typical of unscripted panel speech. #### 👀 Visual learners - Present: none — audio/video panel format with no on-screen diagrams described in the transcript. - Improve: add a diagram of the three-stage trust model (pre-code plan disclosure, in-progress tool-call visibility, post-code audit artifact) and a permission-scoping diagram for "least agency." #### 🔊 Aural learners - Present: the source is itself a spoken panel discussion — well-suited to this learning style as-is. - Improve: provide a shorter audio-only highlight reel of the three-stage trust model and the "least agency" segment for repeat listening. #### 🗣️ Verbal learners - Present: rich definitions-through-discussion (e.g., "least agency," "synchronous vs. asynchronous explainability," "rubber stamping"). - Improve: add a short glossary distinguishing least privilege vs. least agency, and synchronous vs. asynchronous explainability, since both terms are coined/used loosely in the moment. #### 🧩 Kinesthetic learners - Present: concrete, describable practices (sub-agent permission tiers, plan-disclosure step, audit artifact export) that a team could implement directly. - Improve: turn these into a checklist or starter template for scoping a first agentic workflow's permissions and audit trail. #### 🧠 Logical learners - Present: Priyanka's three-stage SDLC trust model is a clear, ordered framework. - Improve: a decision tree for "when does 100% trust mean this should be automation instead of an agent" would formalize Claire's closing point. #### 🧑‍🤝‍🧑 Social learners - Present: multi-panelist format with live Q&A/chat integration is inherently social and well-suited to this style. - Improve: the promised Slack Q&A follow-up (mentioned at the open) is a good structure — ensure it's actually indexed/shared afterward. #### 🧘‍♀️ Solitary learners - Present: the framing question ("do I trust myself that I added all the constraints?" — an audience member's question) invites individual reflection. - Improve: add a self-assessment worksheet for auditing one's own team's current agent guardrails. #### 🌿 Naturalistic learners - Present: none directly — no ecosystem/environment analogies used in the transcript. - Improve: an ecosystem analogy (e.g., agent permission scopes as a food web) could make the "least agency" concept more intuitive, though this would need to be added rather than sourced from the panel. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: not assessable from the transcript alone (no page markup provided). - Improve: ensure the hosted video page includes proper heading structure and a text transcript link (LeadDev typically publishes one). #### Keyboard navigation - Not applicable to this source — this assessment concerns page/player UI, and only the transcript content was available for review, not the hosting page. #### Contrast and readability - Not applicable to this source — no visual design elements were available to assess (only spoken transcript content). #### Text resizing and reflow - Not applicable to this source — no page layout was available to assess. #### Media and captions - Present: a transcript exists and was retrievable via vidIQ, indicating captions/transcript support on the platform. - Improve: publish a cleaned, speaker-attributed transcript (the raw transcript run together across speakers without labels, which this analysis had to disentangle manually) and consider a downloadable version. #### Forms and interactions - Present: live Zoom Q&A feature mentioned for attendees. - Improve: ensure Q&A submission and the promised Slack follow-up channel are both keyboard- and screen-reader-accessible. #### Standards reference - Insufficient information to map to specific WCAG 2.2 AA criteria beyond the captions/transcript point above, since only spoken content (not the hosting page) was available for review. ### 🌍 DEIB Assessment #### Cultural breadth - Present: panelists span UK (Manchester), US (San Mateo), and general North American tech contexts; one audience question specifically comes from London. - Improve: no perspectives from outside North America/UK tech culture; broader international regulatory context (e.g., EU AI Act) isn't discussed despite the governance topic. #### Inclusive language - Present: technical jargon (IAM, MCP, SDLC) is generally explained in context by the panelists or moderator. - Improve: some terms (Agent Gateway, DORA-adjacent metrics) are name-dropped without definition; a glossary would help non-specialist viewers. #### Neurodiversity support - Present: the panel follows a fairly predictable structure (intros, poll, moderated Q&A rounds, audience questions, close). - Improve: no visible agenda or section markers were available in this video's presentation (based on transcript alone); a published outline/timestamp index would help. #### Representation - Present: mixed-gender panel (two women, one man) across different companies, seniority framings, and regions. - Improve: no representation of engineers/managers from outside venture-funded tech (e.g., regulated industries beyond the one audience mention of fintech) actually speaking on the panel itself. #### Psychological safety - Present: explicit discussion of normalizing failure-sharing (the Amy Edmondson reference, the closing point about no one publicly discussing agent failures) and giving developers "the power to make changes" when an agent goes wrong. - Improve: the panel names psychological safety as a goal but doesn't offer a concrete mechanism (e.g., blameless postmortem template) beyond the general encouragement to share. ### ✅ Logical Validity #### Strong reasoning - Causal reasoning: Andrew's argument that trust must live in the surrounding system (not the agent or the operator alone) is supported by the concrete mechanism he offers — golden paths, observability, permission scoping — rather than asserted as a bare claim. - Analogical strength: Priyanka's intern-graduating-to-full-time-employee analogy for agents earning progressively higher-stakes responsibility is apt and consistently reused through the discussion (least agency, staged trust). - Inductive strength: Claire's point that guardrails "have really helped the team to be more confident" is grounded in a described real practice (sub-agent permission tiers) rather than a general assertion. #### Fallacies - Hasty generalization (mild): the claim that stacked review bots make developers "rubber stamp" PRs is asserted from Priyanka's personal experience ("when I read a pull request today, I am lost... I'm rubber stamping it") and generalized to the industry without additional evidence cited in this segment. Fix: cite or gather PR-approval-time data across teams with varying bot-comment volume. - Appeal to absence of a counterexample: no panelist could name a ~100%-trusted agent, which is used to support "there's no trust dashboard" — this is reasonable as an observation but is treated as near-conclusive; a genuinely low-stakes, well-scoped automation-adjacent agent might exist and simply wasn't top-of-mind. #### Tone of voice - Collaborative, reflective, and appropriately uncertain — panelists repeatedly acknowledge the industry is "still in the messy learning stage" rather than presenting solved answers; moderator Jenn Wiggins injects skeptical, pointed follow-ups (e.g., on inflated productivity metrics) that keep the tone grounded rather than promotional. ### 🛡️ DARVO Analysis Not applicable to this source — the transcript is a collaborative panel discussion with no accusation, denial, or victim/offender dynamic present; no party is being confronted or is defending against a claim of wrongdoing. ## 🎯 Conclusion The panel's throughline is that trust in coding agents can't be verified once and then assumed — it has to be continuously earned through system design: scoped, revisited "least agency" permissions; staged disclosure of an agent's plan, actions, and reasoning; and exportable, immutable audit artifacts that let a human reconstruct what happened after something goes wrong. The most urgent near-term risk isn't agent misbehavior itself but human reviewers losing the ability to meaningfully review agent-generated code under rising volume — the fix is agents that explain themselves at a level a developer would recognize as their own work, not agents that generate more text to skim. Practical next steps for readers: audit current agent permission scopes for granularity and revisit them regularly; instrument PR cycle-time and rework metrics (not just token spend) as a proxy for whether review capacity is keeping pace with agentic output; and build (or adopt) a mechanism for exporting per-session, audience-calibrated agent audit trails before an incident forces the issue. ## 🔄 Refactor Appendix — CodeRabbit - How can you trust your AI agents? > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### Trust lives in the system, not the agent > [!quote] ID:rw_y_2vGKvhzaw_01 > "I think it's more about trusting the system that they're both operating within." **Context & use**: - Andrew's answer to whether trust rests in the agent or the human operator. - Reframes "agent trust" as a systems/infrastructure design problem (permissions, observability, golden paths) rather than a model-capability problem — directly useful for anyone building or evaluating agentic tooling. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://y_2vGKvhzaw#H1)  #### Least privilege becomes least agency for agents > [!quote] ID:rw_y_2vGKvhzaw_02 > "the least privilege of traditional IM moves on to least agency" **Context & use**: - Audience member Kieran's term, picked up and used by the panel to describe fine-grained, continuously-revisited sub-agent permissioning. - A namable concept worth tracking as agentic-security vocabulary matures — useful vocabulary for future security/governance notes. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://y_2vGKvhzaw#H2)  #### Stacked review bots cause rubber-stamping > [!quote] ID:rw_y_2vGKvhzaw_03 > "I'm not reading through any of those. I'm rubber stamping it." **Context & use**: - Priyanka describing her own experience reviewing PRs loaded with multiple bot comments. - Names the core current failure mode this whole panel is responding to: more automated review signal can reduce actual human oversight rather than increase it — directly relevant to any code-review tooling decision. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://y_2vGKvhzaw#H3)  ### 🧠 Permanent Candidates (H4) #### [P1] 100%-trusted-agent-should-be-automation **Claim** (one sentence, Courtney's voice): If a workflow would need 100% trust to run unsupervised, it's a signal the workflow should be deterministic automation, not an agent. **Evidence pointer**: [[#Trust lives in the system, not the agent]] **Scope & conditions**: - Holds when: the task has a fixed, enumerable set of correct outcomes and no genuine judgment call. - Breaks when: the task genuinely requires judgment under ambiguity — in that case some level of tolerated variance is inherent to using an agent at all, and the right target isn't 100% trust but a well-instrumented feedback loop. **Links**: - [[Least agency permission scoping]] — because applies-in agent deployment decisions - [[Audit trail design]] — because extends the same "verify, don't assume" posture  ### ✏️ Fleeting Queue - [F1] Look into "Agent Gateway" (Linux Foundation agentic-AI project) as a candidate for session/log aggregation infrastructure — https://www.youtube.com/watch?v=y_2vGKvhzaw #xref #inbox - [F2] Read Amy Edmondson's *Right Kind of Wrong* for the intelligent-failure framing referenced by an audience member — #xref #inbox ### → Things 3 (max 2 actions) - [ ] Review current project's agent permission scopes for "least agency" granularity — engineering practice #things  📄 **Full text:** [[Full Document Contents/Articles/CodeRabbit - How Can You Trust Your AI Agents.md|CodeRabbit - How Can You Trust Your AI Agents? by YouTube]] ## Highlights - agents itself or is it about establishing if you trust the human operators or orchestrators of those agents? >> I think it's actually neither. I think it's more about trusting the system that they're both operating within. Because if you create the golden path for developers to build safely and securely with tools in the right way that have the right levels of observability, then uh it becomes something that's innate to your development process. We're just not there yet. We're in that like messy learning stage. That's why, you know, ([View Highlight](https://read.readwise.io/read/01kxh9fpdnge9a9sqm3rt1zss3)) - Tags: atom/literature/h1 - >> I think it's identity >> IM it's like it's permissions and identity >> okay identity what's it stand for though because we like to identify identity and access management I guess uh moves on So with the agentic workflows, the least privilege of traditional IM moves on to least agency. Interesting choice of word agency. The main difference being the non-deterministic nature of agents. What realistic steps are you adopting to ([View Highlight](https://read.readwise.io/read/01kxh9ftmnegekkp54tssq3esk)) - Tags: atom/literature/h2 - increase the cognitive load on the human. Like when I read a pull request today, I am lost like with so many different comments and all of those are like a huge wall of text. I'm not reading through any of those. I'm rubber stamping it. So the real thing that an AI agent needs to do is make sure that I as a developer can understand it. Can I break down the code that's written into a way that the developer understands, absorbs and feels like, you know, this is what I would have written ([View Highlight](https://read.readwise.io/read/01kxh9fzft8na6m94dw4g3tx3p)) - Tags: atom/literature/h3 - iterate and get there faster? I think it's by bringing uh those skill sets together. They might be the same person now in your org. There's lots of folks who are both those people. Uh, but there's also folks that aren't and you have to find ways to bring them together. >> Absolutely. And I would just add, I think if you have 100% trust in something, you probably should have just done automation. You don't need agents for everything. And that binary is probably like you could have just automated a step. Has anyone found to that point or how ([View Highlight](https://read.readwise.io/read/01kxh9g57qsqyqpmay4a3zyeps)) - Tags: atom/literature/h4