{ "version": "https://jsonfeed.org/version/1.1", "title": "AISDLC Insights", "home_page_url": "https://aisdlc.ai/insights", "feed_url": "https://aisdlc.ai/insights/feed.json", "description": "Original, source-informed analysis of agentic engineering, context systems, harnesses, verifier architecture, agent identity, evidence, and enterprise control.", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "language": "en-US", "items": [ { "id": "https://aisdlc.ai/insights/the-model-is-not-the-architecture", "url": "https://aisdlc.ai/insights/the-model-is-not-the-architecture", "title": "The model is not the architecture", "summary": "Enterprise advantage will not come from renting the same frontier model as everyone else. It will come from engineering the system that turns capability into bounded, repeatable, provable work.", "content_text": "The model is not the architecture\n\nEnterprise advantage will not come from renting the same frontier model as everyone else. It will come from engineering the system that turns capability into bounded, repeatable, provable work.\n\nCapability is rented. Intent, context, identity, tools, verification, evidence, and decision rights are engineered.\n\nThe most common enterprise mistake in agentic engineering is architectural compression: the model is treated as if it were the product, the workflow, the operating model, and the control system at once. It is none of those things. A model is a powerful reasoning component inside a larger sociotechnical system. The quality of that larger system determines whether model capability becomes dependable work or merely faster uncertainty.\n\nObserved signal: The engineering surface is moving outward. Current production accounts increasingly attribute agent performance to repository design, tools, feedback loops, durable state, execution environments, and evaluation—not only to model selection or prompt quality.\n\nCapability is not an operating model\n\nTwo organizations can use the same model and produce radically different outcomes. One gives the agent ambiguous intent, broad credentials, fragmented context, weak tests, and no reliable stop path. The other gives it a versioned objective, a bounded execution substrate, typed tools, independent challenge, and an evidence trail tied to the released artifact. Model capability is held constant; engineered reliability is not.\n\nThis changes where leaders should look for durable advantage. Model access will continue to diffuse. The harder-to-copy asset is the organizational system around the model: how work is specified, how context is assembled, how authority is delegated, how quality is challenged, how runtime behavior is observed, and how evidence is preserved. That system contains operating knowledge, risk appetite, domain judgment, and institutional memory.\n\nModel-centric adoption: Choose a model, then find work for it; Measure output fluency and task completion; Borrow the user’s access and workspace; Treat review as a final human step. System-centric engineering: Define the outcome and authority envelope first; Measure outcome, trajectory, policy, and side effects; Give the agent its own bounded identity and substrate; Engineer verification and evidence across the lifecycle.\n\nThe architecture must survive model change\n\nFrontier models will improve, specialize, and be replaced faster than most enterprise systems can be recertified. Binding identity, approval logic, memory, or evidence semantics to one model creates hidden migration risk. A model upgrade can change tool choice, verbosity, refusal behavior, planning depth, and error modes even when the interface remains stable.\n\nEditorial synthesis: The substitution test. A mature agent architecture can change its model without silently expanding authority, losing run provenance, or invalidating the assurance baseline. When those properties are inseparable from the model, the surrounding system is not yet an enterprise architecture.\n\nFour durable design assets. Executable intent: A versioned statement of outcome, invariants, acceptance criteria, prohibited actions, and accountable ownership. Governed context: A testable assembly process for instructions, knowledge, state, examples, and tools within a finite attention budget. Bounded action: Identity, permissions, substrate, and tool contracts that constrain how reasoning becomes an enterprise effect. Independent proof: Verification, approval, provenance, and runtime evidence that do not depend on the builder’s own confidence.\n\nFund the system of work, not a model showcase\n\nPilots often overinvest in visible generation and underinvest in the invisible infrastructure that makes generation deployable. The result is an impressive demonstration that cannot cross a production gate. A stronger investment thesis begins with reusable organizational capabilities: agent identity, policy enforcement, isolated execution, context services, evaluation infrastructure, evidence storage, and ownership lifecycle.\n\nResearch on AI-assisted development also cautions that AI tends to amplify the strengths and dysfunctions already present in an engineering system. Faster generation cannot compensate for weak specifications, brittle delivery, fragmented ownership, or poor feedback loops. It can make those weaknesses move faster.\n\nArchitecture review questions. Before calling an agentic capability production-ready, ask: What remains stable when the model changes?; Where is the agent’s authority defined, enforced, and expired?; Can a verifier challenge the work without inheriting the builder’s context and assumptions?; Can the exact intent, context, tools, checks, approval, deployment, and runtime outcome be reconstructed?; Who can hold, constrain, revoke, or stop the system when evidence degrades?\n\nAISDLC position: The model is a replaceable capability component. The enterprise architecture is the governed system that makes its work legible, bounded, independently challenged, and attributable.", "date_published": "2026-08-08T12:00:00Z", "date_modified": "2026-08-09T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Operating thesis", "agentic-engineering", "harness-engineering", "execution-substrate", "evidence-engineering" ] }, { "id": "https://aisdlc.ai/insights/context-is-a-runtime-system", "url": "https://aisdlc.ai/insights/context-is-a-runtime-system", "title": "Context is a runtime system", "summary": "Prompt craft still matters. Production reliability now depends on the full state made visible, trusted, current, and actionable at each decision.", "content_text": "Context is a runtime system\n\nPrompt craft still matters. Production reliability now depends on the full state made visible, trusted, current, and actionable at each decision.\n\nThe control surface is everything the agent can see—and every rule that governs how it got there.\n\nA production agent does not act on a prompt alone. It acts on instructions, retrieved knowledge, tool descriptions, files, memory, conversation history, environment state, examples, and the residue of prior actions. Together these inputs form a runtime system. They determine what the model believes is relevant, what it treats as authoritative, and what actions appear possible.\n\nObserved signal: More context is not automatically better context. Current engineering guidance treats model-visible context as a finite resource that must be selected, refreshed, compacted, and sometimes reset. Long-running work depends on durable artifacts that survive beyond any one context window.\n\nFrom prompt writing to context assembly\n\nA prompt is authored text. A context system is a decision about inclusion. It decides which policies outrank user content, which repository files are relevant, which memory is fresh enough to reuse, which tools are exposed, and how much history remains visible. Those decisions can change behavior without changing a single word in the user’s request.\n\nThat makes context assembly an architectural and security boundary. Retrieved text may contain instructions that conflict with policy. Memory may preserve a once-correct conclusion after the environment has changed. Tool descriptions may imply authority that the caller does not possess. A context pipeline must therefore do more than retrieve: it must classify, attribute, prioritize, redact, expire, and test.\n\nA governed context assembly loop. 01 Declare: Bind the run to a versioned objective, risk tier, data boundary, and context policy. 02 Resolve: Select the smallest sufficient instructions, knowledge, tools, state, and examples. 03 Validate: Check provenance, freshness, permissions, conflicts, injection risk, and budget. 04 Manifest: Record what entered context, what was excluded, and which version was used. 05 Evaluate: Test whether context leads to correct decisions and resists known poisoning patterns.\n\nMemory is infrastructure, not truth\n\nDurable memory is essential for work that spans sessions, agents, or model changes. It carries decisions, progress, failures, and operating state forward. Yet persistence creates a new failure mode: a corrupted or stale item can influence many future runs long after its origin has disappeared from view.\n\nObserved signal: Persistence expands the attack surface. Security guidance for agent memory emphasizes provenance, integrity, poisoning defenses, and controlled reuse. The relevant question is not only whether an item was stored, but who created it, under which authority, for what purpose, and when it should expire.\n\nThe minimum context manifest. Identity: Which agent, delegator, and accountable owner initiated the run. Composition: Instruction, policy, retrieval, memory, tool, example, and environment versions. Provenance: Origin, trust class, permissions, freshness, and integrity status for included state. Disposition: What was used, rejected, compacted, superseded, or written back to durable memory.\n\nContext quality must be testable\n\nTeams commonly test model outputs while leaving retrieval and context assembly untested. That misses the mechanism that supplied the model’s evidence and action surface. A context evaluation should test both inclusion and exclusion: whether required policy and domain facts appear, whether irrelevant or unauthorized material stays out, and whether conflicting instructions are resolved in the intended order.\n\nContext-system release evidence. Versioned context policy and precedence rules; Context manifest for representative runs; Retrieval relevance and freshness evaluation; Injection and memory-poisoning challenge set; Redaction and data-boundary results; Compaction and cross-session handoff tests\n\nAISDLC position: Context is a governed runtime asset. It requires an owner, a composition policy, provenance, evaluation, and a durable manifest—not merely a larger prompt window.", "date_published": "2026-08-08T12:00:00Z", "date_modified": "2026-08-09T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Context systems", "context-engineering", "durable-memory", "intent-engineering" ] }, { "id": "https://aisdlc.ai/insights/harness-engineering-is-platform-engineering", "url": "https://aisdlc.ai/insights/harness-engineering-is-platform-engineering", "title": "Harness engineering is platform engineering", "summary": "The model supplies capability. The harness determines whether that capability can plan, act, recover, prove, and stop inside a real engineering environment.", "content_text": "Harness engineering is platform engineering\n\nThe model supplies capability. The harness determines whether that capability can plan, act, recover, prove, and stop inside a real engineering environment.\n\nThe harness is the operating system for bounded agent work.\n\nAgentic engineering shifts a large share of reliability work into the environment around the model. The harness decomposes goals, presents tools, manages context, creates checkpoints, runs tests, handles failure, and decides when to continue, escalate, or stop. The execution substrate supplies the isolated workspace, filesystem, browser, network, identity, and compute in which those choices become effects.\n\nObserved signal: Repository and environment design are becoming agent interfaces. Production accounts describe making repositories legible, tests accessible, state durable, environments isolated, and progress recoverable so agents can complete long-running work across bounded sessions.\n\nA harness must make five promises\n\nFive platform promises. Legibility: The agent can discover architecture, constraints, interfaces, tests, and current work without reconstructing the organization from chat. Boundedness: Tools, network, credentials, compute, and side effects remain inside a declared execution envelope. Recoverability: Progress and failures survive context resets; retries introduce new evidence instead of repeating the same action. Verifiability: The harness exposes deterministic checks, evaluator interfaces, logs, and artifacts to independent challenge. Interruptibility: Humans and policy systems can hold, narrow, revoke, or stop work at meaningful enforcement points.\n\nThese promises are platform responsibilities because every product team should not reinvent them. A reusable harness can standardize isolated workspaces, credential brokering, tool schemas, run manifests, checkpoint formats, evaluation hooks, and evidence emission. Product teams then specialize intent, domain context, tools, and acceptance criteria without rebuilding the control foundation.\n\nSeparate reasoning, action, and durable state\n\nThe reasoning model, execution environment, and durable session state change on different timelines. Treating them as one process makes upgrades fragile and incident recovery opaque. A strong architecture allows a model to be replaced, a workspace to be quarantined, or a session to be resumed without losing the attributable record of what happened.\n\nThe bounded run loop. 01 Plan: Translate executable intent into bounded work units and explicit completion conditions. 02 Provision: Create an isolated substrate with purpose-bound identity, tools, data, network, and resource limits. 03 Act: Execute through typed contracts that preview and record consequential effects. 04 Challenge: Run deterministic checks and independent evaluators against outcome, trajectory, and policy. 05 Checkpoint: Persist progress, evidence, unresolved questions, and safe continuation state. 06 Dispose: Merge, escalate, quarantine, revoke, or destroy the workspace according to outcome.\n\nFailure must be a first-class system state\n\nNaive agent loops treat every failure as a reason to retry. Mature harnesses distinguish transient infrastructure failure, insufficient context, invalid intent, tool rejection, verifier disagreement, policy denial, and exhausted budget. Each state requires a different recovery action. Repeating the same plan after the same evidence is not resilience; it is an uncontrolled loop.\n\nImplementation position: No blind retry. Every retry should name the new evidence, changed condition, narrowed scope, or alternative method that makes another attempt rational. Otherwise the run should stop or escalate.\n\nAgent wrapper: Single prompt loop; Shared developer workspace; Static tool list; Transcript as state; Retry until completion. Enterprise harness: Planner, executor, verifier, and disposition states; Isolated task substrate; Policy-filtered capability envelope; Versioned checkpoint and run ledger; Evidence-aware recovery and stop conditions.\n\nPlatform backlog. Repository and service legibility contract; Isolated task environments and identity brokering; Typed tool registry with effect classification; Durable checkpoint and handoff format; Independent evaluator interface; Run ledger and evidence schema; Budget, back-pressure, quarantine, and stop controls\n\nAISDLC position: Harness engineering is not prompt decoration. It is the platform discipline that makes agent work repeatable, inspectable, recoverable, and governable across models and teams.", "date_published": "2026-08-08T12:00:00Z", "date_modified": "2026-08-09T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Platform architecture", "harness-engineering", "execution-substrate", "tools-and-protocols", "durable-memory" ] }, { "id": "https://aisdlc.ai/insights/verification-is-a-plane-not-a-phase", "url": "https://aisdlc.ai/insights/verification-is-a-plane-not-a-phase", "title": "Verification is a plane, not a phase", "summary": "A builder can test its own work. It cannot independently accept the risk created by that work.", "content_text": "Verification is a plane, not a phase\n\nA builder can test its own work. It cannot independently accept the risk created by that work.\n\nIndependent challenge must cross the lifecycle, not wait at the end of it.\n\nAgentic systems can fail before code exists and after deployment succeeds. The objective can be wrong, the context can be compromised, the tool boundary can be too broad, an evaluation can be invalid, or runtime behavior can drift. A conventional test phase sees only a fraction of this surface. Verification must become a continuous plane of independent challenge.\n\nObserved signal: Agent evaluation is a system problem. Current evaluation practice distinguishes outcomes, trajectories, graders, tasks, environments, repeated trials, and human judgment. Benchmark integrity and infrastructure configuration can materially affect the result.\n\nIndependence is an architecture property\n\nAdding another agent does not automatically create independent verification. Two agents using the same model, context, tools, assumptions, and objective may reproduce the same blind spot. Independence comes from separation: different evidence, methods, prompts, models where useful, tool access, organizational accountability, and decision rights.\n\nNor should a model grader be treated as an approval authority. Model-based evaluation is valuable for coverage and scale, especially when calibrated against expert judgment. But authorization is a risk decision owned by an accountable human role or an explicitly delegated policy mechanism. A verifier supplies findings; an authority decides disposition.\n\nA heterogeneous verifier plane. Deterministic checks: Tests, types, policy rules, schemas, invariants, simulations, and reproducible security scans. Evaluator agents: Adversarial or rubric-based challenge of outcomes and trajectories, calibrated against expert decisions. Domain review: Human judgment for clinical, legal, operational, experience, or business correctness where models lack authority. Runtime monitors: Behavior, policy, anomaly, drift, and side-effect detection after release.\n\nEvery verifier needs a risk hypothesis\n\nA verification catalog should not be a flat list of generic checks. Each verifier should name the failure it is designed to detect, the evidence it requires, its independence boundary, its false-positive cost, and the authority that receives an unresolved finding. This makes verification composable and prevents a green dashboard from becoming false assurance.\n\nChallenge across the lifecycle. Intent Challenge the objective: Is the use case legitimate, bounded, measurable, and assigned to an accountable owner? Design Challenge the architecture: Can the agent bypass identity, policy, data, tool, or stop boundaries? Build Challenge the implementation: Do tests cover trajectories, side effects, security, and uncertainty—not only happy-path output? Release Challenge the evidence: Does the package bind to the exact artifact and show who had authority to approve it? Run Challenge the operating state: Are behavior, drift, incidents, ownership, and evidence quality still inside the authorized operating envelope?\n\nVerifier disagreement is information\n\nWhen verifier methods disagree, averaging the scores can erase the most important signal. Disagreement may indicate ambiguity, a brittle rubric, infrastructure noise, or a genuinely uncertain outcome. The system should preserve the competing findings, identify which risk each method addresses, and route material uncertainty to the accountable authority.\n\nImplementation position: No builder accepts its own risk. The system that generates a consequential artifact may test and critique it, but final acceptance must be performed by an independent verifier and the designated authorization authority for that risk tier.\n\nVerifier record. Risk hypothesis and scope; Method, model, tool, rubric, and environment versions; Independence boundary from the builder; Inputs, outputs, confidence, and known limitations; Resolved and unresolved findings; Escalation and disposition authority; Link to the exact artifact or run evaluated\n\nAISDLC position: Verifiers challenge. They do not silently become approvers. Human accountability and explicit decision authority remain visible even when verification is highly automated.", "date_published": "2026-08-08T12:00:00Z", "date_modified": "2026-08-09T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Independent assurance", "multi-agent-verification", "eval-driven-development", "observability-control" ] }, { "id": "https://aisdlc.ai/insights/every-agent-is-a-governed-principal", "url": "https://aisdlc.ai/insights/every-agent-is-a-governed-principal", "title": "Every agent is a governed principal", "summary": "If an agent can take consequential action, it needs its own attributable identity, a delegator, a purpose, an authority envelope, and an expiry.", "content_text": "Every agent is a governed principal\n\nIf an agent can take consequential action, it needs its own attributable identity, a delegator, a purpose, an authority envelope, and an expiry.\n\nAn agent is neither a person nor a conventional application. Its identity lifecycle must expose who is accountable for every delegated action.\n\nAn agent that acts through a human’s session is difficult to distinguish from the human, difficult to revoke independently, and difficult to govern as its purpose changes. Borrowed credentials collapse accountability. They obscure whether a person, service, model, or policy mechanism selected the action and which authority actually permitted it.\n\nObserved signal: Enterprise identity is extending to agents. Current identity guidance is beginning to distinguish agent identities from workforce users and conventional applications, with explicit ownership, sponsorship, delegated rights, lifecycle, and auditability.\n\nCreate identity before granting credentials\n\nA credential proves that a caller possesses a secret or token. It does not explain why the action is legitimate. Agent identity must connect the technical principal to its sponsor, accountable owner, approved purpose, risk tier, deployment, model and harness versions, data classes, tools, review date, and kill authority.\n\nThis system record becomes the anchor for policy and evidence. When an agent requests a tool, the policy decision can evaluate not only the credential but the current purpose, resource, action, environment, transaction limit, time window, and required approval. The resulting effect remains attributable to the agent and to the human or service that delegated the work.\n\nThe delegation envelope. Principal: A unique non-human identity for the agent instance or governed service. Accountability: A named sponsor and operational owner who can answer for purpose, performance, and retirement. Purpose: The approved outcome and data use that justify access. Authority: Allowed actions, resources, limits, environments, approvals, and explicit prohibitions. Time: Start, expiry, recertification, suspension, and revocation conditions.\n\nProtocol compatibility is not permission\n\nAgent protocols make tools and other agents easier to discover and invoke. That expands capability; it does not establish trust. An enterprise authorization layer must still decide whether this principal may perform this action on this resource for this purpose now. Natural-language tool descriptions should never substitute for an enforceable policy decision.\n\nObserved signal: Authorization patterns are still evolving. Enterprise-managed authorization is emerging in agent tool protocols, while standards initiatives continue to develop. Implementations should version protocol and policy assumptions instead of treating today’s profile as settled.\n\nAuthority must expire when purpose or ownership does\n\nAgents can become orphaned when a project ends, an owner changes roles, a vendor contract expires, or an integration is replaced. If access survives those events, the technical system has separated authority from accountability. Recertification should therefore trigger on time and on material change: owner, purpose, risk tier, model, harness, tool, data source, environment, or operating outcome.\n\nIdentity lifecycle. Register Create the system record: Name the purpose, sponsor, owner, tier, technical identity, boundaries, and kill authority. Authorize Issue bounded access: Grant only the actions, resources, environments, and duration required for the approved purpose. Observe Link action to authority: Record policy decisions, delegated chains, tool effects, approvals, and outcomes. Recertify Revalidate the operating envelope: Reassess on schedule and whenever material identity, purpose, model, tool, or data state changes. Retire Revoke before archive: Stop events, remove credentials and access, preserve evidence, and confirm the system can no longer act.\n\nMinimum agent system record. Unique agent identity and deployment IDs; Executive sponsor, accountable owner, and operations owner; Approved purpose, risk tier, and prohibited uses; Model, harness, tool, data, and environment versions; Delegation and approval policy; Review date, material-change triggers, and status; Suspend, revoke, stop, and retirement authorities\n\nAISDLC position: No accountable owner, no current purpose, no production authority. Agent identity is the thread that connects delegated action to human accountability.", "date_published": "2026-08-08T12:00:00Z", "date_modified": "2026-08-09T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Identity and authority", "agent-identity", "tools-and-protocols", "observability-control", "execution-substrate" ] }, { "id": "https://aisdlc.ai/insights/evidence-before-autonomy", "url": "https://aisdlc.ai/insights/evidence-before-autonomy", "title": "Evidence before autonomy", "summary": "Autonomy should expand only when the organization can prove what the system did, why it was allowed, how it was challenged, and how it can be stopped.", "content_text": "Evidence before autonomy\n\nAutonomy should expand only when the organization can prove what the system did, why it was allowed, how it was challenged, and how it can be stopped.\n\nAutonomy is an evidence-backed operating state, not a permanent product feature.\n\nEnterprises often discuss autonomy as a binary capability: either the agent acts independently or a human remains in the loop. Real operating models need a richer control surface. An agent may read broadly but write narrowly, propose a transaction but not commit it, execute within a limit, or continue only while runtime evidence remains inside an authorized operating envelope.\n\nEditorial synthesis: Autonomy is a dynamic policy decision. Useful autonomy is the current combination of identity, purpose, risk tier, tool effect, transaction limit, evidence quality, runtime state, and available intervention—not a fixed property of the model.\n\nEvidence is the operating memory of accountability\n\nA transcript can show what a model said. It cannot, by itself, establish which specification applied, what context was visible, which identity held authority, which tool effect occurred, which verifier challenged the result, who approved release, or what exact artifact ran. Evidence engineering connects these elements with stable identifiers and versioned records.\n\nSoftware supply-chain provenance provides an important foundation: released artifacts should be attributable to the process that built them. Agentic systems require that chain to extend in both directions—back to intent, context, and delegated authority, and forward to deployment, runtime decisions, outcomes, incidents, recertification, and retirement.\n\nThe evidence spine. Intent Why the work exists: Objective, owner, risk tier, constraints, acceptance criteria, and prohibited outcomes. Build What produced the artifact: Agent, model, harness, context, tools, environment, changes, tests, and provenance. Challenge How the work was contested: Verifier identities, methods, findings, disagreements, remediations, and residual risk. Authorize Who accepted the decision: Approval authority, policy result, conditions, scope, expiry, and exact artifact binding. Operate What happened in reality: Run traces, interventions, outcomes, drift, incidents, overrides, and lifecycle disposition.\n\nObservability is necessary. It is not control.\n\nTelemetry can reconstruct behavior and reveal anomalies. A control plane uses that evidence to decide what may happen next. It evaluates identity and policy, obtains approvals, constrains tool effects, holds uncertain actions, revokes authority, quarantines execution, and stops systems. A dashboard without enforcement can explain a harmful action beautifully while remaining unable to prevent the next one.\n\nObserved signal: Agent telemetry is becoming more structured. Observability conventions for generative AI are developing across traces, metrics, and events, while monitoring guidance emphasizes the difficulty of understanding deployed AI behavior. Telemetry design should therefore preserve limitations and connect signals to response authority.\n\nAutonomy must be promotable and reversible\n\nOrganizations frequently design a path to increase autonomy but no path to reduce it. That creates a one-way ratchet even when ownership changes, evidence quality falls, drift appears, or incident patterns emerge. The operating model should support promotion, hold, degradation, suspension, and retirement as normal states.\n\nStatic autonomy: Configured once at product launch; Human review added to every action or removed entirely; Success measured by completion rate; Telemetry retained for investigation. Evidence-adaptive autonomy: Operating envelope recalculated from tier, effect, and runtime state; Human attention reserved for consequential uncertainty; Success includes policy adherence, side effects, and outcomes; Evidence triggers allow, hold, constrain, revoke, and stop decisions.\n\nPromotion criteria. Repeated performance: Representative evaluations and production outcomes remain inside declared thresholds across time and conditions. Independent assurance: Verifier coverage addresses the material risk hypotheses and unresolved disagreement is dispositioned. Complete evidence: Runs are attributable to intent, identity, versions, tool effects, approvals, and outcomes. Operational control: Hold, degrade, revoke, quarantine, rollback, and stop paths are tested and owned.\n\nControl-plane acceptance questions. Which actions are observed versus actually intercepted?; Can the system deny or hold an action before the enterprise effect occurs?; Is approval bound to a specific action, artifact, purpose, and expiry?; Does every run preserve the identity and delegation chain?; What evidence automatically narrows the autonomy envelope?; When was revocation, quarantine, rollback, or stop last exercised?\n\nAISDLC position: Agents build. Verifiers challenge. Humans authorize. The control plane enforces. Autonomy is earned through evidence and remains contingent on observable, reversible control.", "date_published": "2026-08-08T12:00:00Z", "date_modified": "2026-08-09T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Evidence and control", "evidence-engineering", "observability-control", "eval-driven-development", "agent-identity" ] }, { "id": "https://aisdlc.ai/insights/own-the-speed", "url": "https://aisdlc.ai/insights/own-the-speed", "title": "Own the speed", "summary": "The goal is not to slow generation. It is to redesign the system that turns generated work into trusted change.", "content_text": "Own the speed\n\nThe goal is not to slow generation. It is to redesign the system that turns generated work into trusted change.\n\nWhen implementation accelerates, the organization must expand its capacity to decide, verify, integrate, release, and learn.\n\nAI can make implementation locally faster while making the delivery system globally slower. One engineer can begin more changes, explore more variants, and open more pull requests. Yet every useful change still consumes shared capacity: someone must decide whether it matters, verify that it works, integrate it with concurrent work, authorize the relevant risk, release it, and learn whether it improved the outcome. When those capacities remain fixed, faster generation creates a larger queue rather than a faster enterprise.\n\nObserved signal: The bottleneck is moving downstream. Current engineering accounts report agent-generated pull requests consuming review bandwidth, while DORA frames AI as an amplifier of the strengths and weaknesses already present in the delivery system. Increasing output at one stage does not remove constraints elsewhere.\n\nIndividual acceleration can become organizational drag\n\nMatt Dailey calls the coordination pain created by this mismatch “velocity sickness.” It is a useful practitioner term, not a clinical diagnosis or an established research construct. The underlying pattern is familiar from flow engineering: work arrives faster than the system can absorb it, decisions disappear into private channels, work in process grows, branches diverge, review becomes shallow, and completed code waits without becoming trusted value.\n\nThe wrong responses sit at opposite extremes. One is institutional rejection: preserve every manual step because acceleration feels destabilizing. The other is uncontrolled concurrency: treat generation volume as productivity and make reviewers, quality teams, and release authorities absorb the consequences. Refusing to adapt leaves value on the table. Removing challenge and accountability does not create adaptation; it creates hidden risk.\n\nObserved signal: “10×” is not a universal empirical result. A randomized study of 16 experienced open-source contributors and early-2025 tools found longer completion times in that narrow setting, and its authors explicitly caution against generalizing the result. Team, task, repository, tool generation, and operating model all shape realized speed.\n\nLocal speed: Prompts completed; Code generated; Branches opened; Pull requests submitted; Tasks started in parallel. System throughput: Outcomes selected and specified; Changes independently challenged; Work integrated without divergence; Risk decisions made by named authorities; Released value adopted and measured.\n\nEngineer the absorption capacity\n\nGeneration is only one capacity in the system of work. The effective throughput of a delivery path is bounded by its slowest necessary stage: intent, generation, verification, decision, integration, release, or adoption. The relevant executive question is therefore not “How many times faster can engineers produce code?” It is “Which constraint now prevents trustworthy change from reaching the enterprise?”\n\nThe trusted-change capacity chain. Intent Choose and bound the right work: Create shared, versioned decision packets with the outcome, constraints, acceptance criteria, owner, and explicit non-goals. Generate Create inside bounded workspaces: Use isolated branches and task envelopes so parallel agents can move quickly without silently colliding or expanding scope. Verify Scale independent challenge: Fuse deterministic checks with independently owned evaluator agents and targeted human judgment before release. Decide Reserve human attention for consequence: Route routine, low-risk dispositions through policy and preserve named human authority for material uncertainty and release. Integrate Control the merge surface: Limit work in process, keep changes small, sequence dependencies, automate merge policy, and make branch ownership visible. Learn Close the outcome loop: Measure adoption, stability, rework, incidents, and realized value—not merely output volume or agent utilization.\n\nEditorial synthesis: The absorption-gap equation. System throughput is constrained by the minimum effective capacity across generation, decision, review, verification, integration, release, and adoption. Increasing only generation widens the queue; increasing the binding constraint improves flow.\n\nPush through rejection by changing the mechanism\n\nAn organization owns the speed when recurring friction becomes engineering input. A repeated review comment becomes a lint, test, verifier, or repository instruction. A lost decision becomes a versioned specification. A merge collision becomes a decomposition and ownership rule. A quality bottleneck becomes a risk-based verifier lane. A slow approval becomes an explicit decision-rights and evidence design problem. The aim is not to bypass the people who carry judgment; it is to stop spending their judgment on checks the system can perform consistently.\n\nSix capacity moves. Durable decisions: Move intent, tradeoffs, constraints, and acceptance criteria out of disposable agent chats and into shared versioned artifacts. Bounded work in process: Limit concurrent changes to the review and integration capacity available for that risk lane. Small, attributable changes: Prefer narrow units that can be understood, challenged, reverted, and owned without reconstructing an entire agent session. Independent verifier capacity: Automate repeatable checks, maintain segregation from the builder, and route disagreement to a named authority. Risk-adaptive flow: Do not make a documentation fix and a consequential transaction system wait in the same review and approval lane. Outcome learning: Track stability, adoption, review latency, rework, and decision quality alongside delivery frequency.\n\nThis changes the role of quality assurance, architecture, security, risk, and operations. They should not become a larger manual queue behind an unlimited generator. Their expertise should define reusable constraints, adversarial scenarios, verifier contracts, evidence requirements, exception paths, and stop conditions that operate at agentic speed. Human review remains essential where judgment and authority are essential; everything repeatable around that judgment should become system capacity.\n\nExecutive questions for agentic velocity. Where is work accumulating after generation?; Which decisions are trapped in private chats or unreviewed plans?; How much concurrent work can verification and integration actually absorb?; Which recurring reviewer judgments can become deterministic checks or independent verifier contracts?; Are risk tiers creating different flow lanes, or merely different labels on the same queue?; Do throughput measures include stability, rework, adoption, and human cognitive load?; Who owns the next constraint when generation is no longer the bottleneck?\n\nAISDLC position: Do not reject the speed. Do not confuse output volume with value. Redesign the delivery system so generation, independent verification, human decision authority, integration, and learning can move as one accountable flow.", "date_published": "2026-08-09T12:00:00Z", "date_modified": "2026-08-09T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Operating thesis", "agentic-engineering", "intent-engineering", "harness-engineering", "multi-agent-verification", "human-accountability" ] }, { "id": "https://aisdlc.ai/insights/train-the-judgment-not-the-tool", "url": "https://aisdlc.ai/insights/train-the-judgment-not-the-tool", "title": "Train the judgment, not the tool", "summary": "Models and interfaces will keep changing. The durable capability is knowing what to delegate, how to bound it, what evidence to demand, and when a human must say no.", "content_text": "Train the judgment, not the tool\n\nModels and interfaces will keep changing. The durable capability is knowing what to delegate, how to bound it, what evidence to demand, and when a human must say no.\n\nAgentic-engineering education should make judgment visible in independently challengeable work—not equate content completion with competence or authority.\n\nAgentic-engineering programs are often organized around a tool menu: prompt features, model interfaces, framework syntax, and a demonstration that ends when the agent produces something plausible. Those skills can be useful, but they decay as products change. They also leave the central production question unanswered: can the practitioner decide what should be delegated, constrain how the work is performed, recognize when the result is unreliable, and assemble evidence that an independent reviewer can challenge?\n\nObserved signal: Confidence and measured effect can diverge. A randomized study of 16 experienced contributors working in familiar open-source repositories found slower completion with the early-2025 AI tools tested even though participants expected the tools to make them faster. The authors explicitly warn against generalizing the result to other developers, tasks, repositories, tools, or later model generations. The defensible lesson is narrower: experience and confidence do not guarantee calibrated judgment about AI assistance.\n\nName the judgment the work requires\n\nJudgment in this discipline is not a vague seniority trait. It is a set of observable decisions: selecting an outcome worth automating; decomposing it into bounded work; separating trusted instruction from untrusted data; choosing an execution envelope; assigning independent verifiers to material failure hypotheses; interpreting disagreement; and reserving release authority for a named human. Each decision can be stated, inspected, challenged, and improved.\n\nAccess to capable models is spreading, but access is not uniform and it does not erase differences in price, latency, privacy, context, or contractual terms. More importantly, model access alone does not supply an operating system for dependable work. DORA’s 2025 research frames AI as an amplifier of the engineering system in which it is introduced. It does not establish that a particular course, curriculum, or tool produces better outcomes. It does make the surrounding system—feedback quality, delivery practice, leadership, and organizational conditions—part of any serious adoption discussion.\n\nTool-familiarity training: Reproduce a demonstration; Memorize the current interface; Treat generated output as the endpoint; Use course completion as the success signal. Judgment-transfer practice: Bound a consequential decision; Explain the authority and context envelope; Produce an artifact another party can try to disprove; Use findings and dispositions as learning evidence.\n\nMake practice produce something challengeable\n\nA field exercise becomes useful when it creates more than activity. It should state a driving question, constrain the work, name the expected artifact, identify an independent reviewer, define what that reviewer attempts to disprove, and specify what happens when the challenge succeeds. The learner is then practicing the same separation of construction, verification, evidence, and authority that a production lifecycle requires.\n\nThe evidence-first stage contract. A bounded question: State the decision or engineering problem before introducing a tool, model, or technique. A reviewable artifact: Produce a manifest, threat model, evaluation set, control trace, decision record, or other object that persists beyond the exercise. An independent challenge: Name a reviewer who did not produce the work and give that reviewer a concrete failure hypothesis to test. A recorded disposition: Capture pass, fail, correction, hold, or escalation and the evidence that supports it; do not silently edit away the failed attempt.\n\nEditorial synthesis: Measure transfer across the system. DORA’s AI research treats organizational conditions as consequential, while the SPACE framework treats developer productivity as multidimensional rather than reducible to one activity measure. Neither source validates this curriculum or establishes a causal training method. AISDLC draws a practical inference from them: judge learning transfer through several operational signals—including artifact quality, review findings, rework, flow, outcomes, and human cognitive load—not attendance, prompt volume, or output count alone.\n\nPractitioner talks can help teams name emerging patterns and imagine new software interfaces. Andrej Karpathy’s “Software Is Changing (Again),” for example, is included here as a thought-leadership lens, not as empirical proof of a learning model. A source-disciplined curriculum keeps those roles visible: research supports only the claim it tested; operating guidance informs practice; practitioner experience supplies hypotheses; and the organization’s own artifacts and outcomes determine whether transfer occurred locally.\n\nCompletion is not standing\n\nThe AISDLC Field Curriculum is public reference material. Its four paths and twenty-six stages can structure individual study or team practice, but finishing a path does not certify a practitioner, prove that an exercise passed independent review, confer authority, or satisfy an enterprise gate. Any team adopting a path must route the resulting work through its own review, authorization, and recordkeeping system. That limitation is not a footnote; it is the lesson. In a governed lifecycle, a claim becomes dependable only when its evidence and decision authority are explicit.\n\nUse a learning path as operating practice. A team can make the public curriculum useful without turning it into a credentialing system: Choose one path that corresponds to a real capability gap, not the newest tool.; Run a small number of stages at a pace the assigned reviewers can genuinely challenge.; Store exercise artifacts and dispositions in the team’s own governed system of record.; Keep the producer and verifier separate; rotate roles without allowing self-approval.; Translate recurring findings into repository guidance, deterministic checks, verifier contracts, or control backlog items.; Evaluate transfer with multiple outcome and workload signals, and record where the evidence remains inconclusive.\n\nAISDLC position: The durable output of agentic-engineering education is better bounded decisions and a body of independently challenged work. Teach tools in service of that judgment, never as a substitute for it; and never turn course completion into an authority claim.", "date_published": "2026-08-11T12:00:00Z", "date_modified": "2026-08-11T12:00:00Z", "authors": [ { "name": "AISDLC Editorial", "url": "https://aisdlc.ai" } ], "tags": [ "Operating thesis", "agentic-engineering", "multi-agent-verification", "evidence-engineering", "human-accountability" ] } ] }