Software Solutions with LLM Agents: Governance and Feedback with Success

Introduction

LLM Agents have crossed from novelty into everyday tooling. The question is no longer whether to use them — it is how to integrate them into professional software development in a way that produces maintainable, extendable, and trustworthy results.

The answer is not a new methodology. It is the disciplined application of practices already present in professional software teams — governance, structured workflow, feedback loops, and quality gates — extended to cover the LLM Agent as a first-class collaborator.

This article covers:

• Governance as a first-class engineering concern
• The assignment lifecycle and its mapping to familiar workflow concepts
• Iterative implementation with quality gates
• Lessons learned as a living feedback loop
• Testing standards for LLM-assisted development
• Cost of operations: the real cost of skipping structure
• Advanced: building a portable, reusable framework

Governance: System Prompts as Process Control

Governance in LLM Agent systems maps directly to process controls familiar in any software team: coding standards, branching rules, definition of done, and review gates. The difference is the delivery mechanism — here, governance is expressed as persistent instructions given to the agent before any work begins.

A system prompt is not a one-time instruction. It is the standing operating procedure for every session.

A well-structured system prompt includes:

Key principle: Governance is about process control, not task specification. Keep system prompts high-level and stable. Task-specific detail belongs in the assignment. A system prompt that is too specific becomes noise and degrades the agent’s ability to apply it consistently.

What Belongs in Governance

• “Always ask questions before proceeding if anything is unclear — do not guess”
• “Follow [language/framework] coding standards for all output”
• “Do not use external tools without explicit approval”
• “Examine code for type safety before marking work complete”
• “Do a git commit after each unit of work is completed and approved”
• “Always ask: do you have any questions before proceeding?”

Engineering principles — SOLID, DRY, GRASP, and architectural standards — are a separate governance artifact that defines the minimum quality bar for all LLM-generated code. They apply to every code generation, modification, and review, and are referenced explicitly in the agent’s instructions. See governance/engineering-principles.md.

What Does Not Belong in Governance

Task requirements, feature specifications, and implementation details belong in the assignment — not the system prompt. Governance that is too specific becomes unreliable. Think of it as the difference between a team charter and a ticket description.

Guardrails vs. Instructions

Governance has two distinct layers serving different functions:

Instructions describe preferred behavior — communication style, workflow expectations, quality standards. They are flexible guidance that shapes how the agent works.

Guardrails are non-negotiable constraints. They apply regardless of context, phrasing, workflow step, or accumulated instruction. They cannot be softened or overridden.

Examples of guardrails:

• git push is never executed without explicit per-session permission — phrases like “deploy,” “ship it,” or “push the branch” are not permission
• No external tool use without approval
• No implementation without HITL approval — the plan must be approved before work begins
• No fabrication — if the answer is not known, the agent says so explicitly

Separating guardrails from instructions matters because constraints mixed into a list of style preferences will eventually be treated as flexible. A guardrail in its own explicitly named section will not.

Technology-Specific Overlays

Base governance is technology-agnostic. For teams working in a specific stack, a second layer — the technology overlay — extends the base with stack-specific rules:

• Language-specific coding standards and idioms
• Known pitfalls: dependency version conflicts, async patterns, build quirks
• Testing conventions for the ecosystem

Overlays compose with the base system prompt rather than replacing it. A Python project loads base governance plus library/python/instructions.md. A Node.js project loads the base plus library/node/instructions.md. This keeps base governance universal while adding precision where the stack requires it.

Work Modes, Agent Roles, and Autonomy

Governance defines the rules. A complementary system defines the operating stance the agent takes during any given piece of work: the mode, the role, and the autonomy level. Together, these prevent one of the most common collaboration failure modes — the agent behaving in a way that doesn’t match the kind of work actually happening.

Work Modes

Every task exists in one of three modes:

Detecting the active mode and naming it explicitly when it shifts prevents mismatched expectations. A Deliver-mode session that pivots to open architectural questions has changed modes; the agent should name the shift rather than operate with mixed signals.

Agent Roles

Within a mode and topic, the agent’s stance is defined by its role:

Roles shift by mode and topic. The Mode-Role Matrix maps the default role for each mode × topic combination:

The full matrix with escalation rules and lateral thinking guidance is in governance/agent-roles-guide.md.

Autonomy Levels

Autonomy levels control how much the agent interrupts, questions, and proactively contributes:

Default: Level 1 (Inform). The technologist sets the level explicitly; it applies until changed. The level can be raised for a design discussion and lowered for a focused implementation sprint within the same project.

The Assignment as a Unit of Work

The assignment is the primary unit of directed work in LLM Agent collaboration. It maps to familiar concepts across workflow systems:

These are reference points, not rigid mappings. The concepts translate across methodologies; the specific terminology is secondary.

The Assignment Lifecycle

A well-executed assignment moves through six phases, in order. Skipping phases — especially the HITL Approval Gate — compounds risk downstream.

Phase 1: Introduction Establish context: what is being built, why it matters, what constraints apply, and what success looks like. Surface relevant lessons from prior work before proceeding.

Phase 2: Q&A and Refinement The agent asks questions; the technologist answers them. Scope is defined. Ambiguities are resolved before implementation begins — not discovered mid-execution.

“If you don’t know, don’t guess. Ask me.”

This instruction should be standing governance and repeated at intake. An agent that asks good questions at this phase is doing its job well.

Phase 3: Scope Management and Deferments Explicit decisions about what is in scope, what is deferred, and why. Deferred items are captured in writing, not dropped. Scope creep during implementation is a failure mode that governance prevents.

Phase 4: Finalization No open questions remain. Testing requirements — unit and integration — are specified. The implementation plan is written by the agent and approved by the technologist. This is the HITL Approval Gate.

ADR (Architecture Decision Record): For higher-impact changes — new dependencies, architectural shifts, breaking changes — an ADR is a delivery requirement, not optional documentation. It captures the decision, the alternatives considered, and the rationale.

Phase 5: Implementation Execution proceeds against the approved plan. See The Iterative Implementation Loop below.

Phase 6: Retrospective (required — not optional) After implementation completes, lessons are captured per source (agent, technologist, tech stack) and folded back into governance and future assignments. The retrospective is the closing mechanism of the feedback loop. Skipping it under time pressure is how the same mistakes compound across assignments.

The Iterative Implementation Loop

The iterative loop implements the ReAct pattern — the standard execution model underlying most agent frameworks: Reason about what to do next → Act (implement the unit) → Observe the outcome (validate, check for regressions) → reason about the next unit. Each iteration is one complete Reason → Act → Observe cycle.

Once implementation begins, work proceeds in small, independently committable units. This is not a stylistic preference — it is the mechanism that keeps work safe, reviewable, and recoverable.

Planning → Scheduling → Execute → Validate → Commit → Iterate
              ↑                                            |
              └────────────────────────────────────────────┘
                         (until plan complete)
                                 ↓
                          Final Review → Close

Each iteration:

1. Select the next small unit of work from the approved implementation plan
2. Implement the unit, including tests
3. Build, test, and verify — no exceptions
4. Commit (git commit per unit, with a descriptive message)
5. Update implementation plan status
6. Select the next unit; repeat

Key principles:

• One unit of work per iteration — commit before moving to the next
• Small, tested, incremental commits produce a clean, legible git history
• Each unit must be independently committable without breaking the build
• Model selection matters: match model capability to step complexity to balance quality and cost — planning and reasoning steps warrant a more capable model; mechanical implementation steps may not

Special operations (governed, not assumed):

• Git branch creation and merge rules — defined in governance
• System utility usage — explicitly permitted or restricted
• Tool access — governed per the system prompt

Quality Gates

Quality gates are checks performed at defined points in the implementation loop. They are not a checklist to rush through — they are the mechanism that prevents technical debt from compounding between units of work.

Two gate types:

• Intermediate Gate — between each unit of work
• Final Gate — at assignment completion

Intermediate Gate (per unit of work)

• Code builds without errors or warnings
• New tests pass; no regressions in existing tests
• Code meets formatting and style standards
• Dependencies are correctly versioned (check the framework)
• Git commit is clean, atomic, and descriptively messaged
• Type safety examined

Final Gate (assignment completion)

Code quality:

• Well-formatted, standards-compliant code
• Correctly versioned dependencies (verify against framework/lockfile)
• No missing or unavailable dependencies
• Builds without errors or warnings
• Expected artifacts are produced

Testing:

• All tests pass without errors or warnings
• Integration test coverage: golden path / must-always-work at 95%+
• Unit test coverage at 80%+
• Smoke test passes (basic CLI or API operations function as expected)
• Log output contains expected content

Review:

• Implementation plan fully completed
• Assignment goals validated against original scope
• All TODOs listed and triaged — required vs. deferred
• Branches cleaned up after merge
• Lessons learned updated (all three sources)

Design integrity:

• Type safety reviewed for clarity, security, and ease of use
• Domain-Driven Design patterns applied where appropriate
• YAGNI check: no abstractions added beyond what the assignment requires
• Behavior consolidation reviewed: workflow management, API management, business logic, data isolation, UI orchestration

Lessons Learned as a Feedback Loop

Lessons learned are the compounding mechanism of LLM Agent collaboration. They prevent repeated mistakes, encode proven patterns, and improve both agent output quality and technologist decision-making over time.

Three sources — all required:

The feedback cycle:

Assignment → Retrospective → Capture (3 sources) → Update Governance → Next Assignment
                                                           ↓
                                              (compounding improvement)

The LLM Agent forgets between sessions. The lessons learned file does not. Maintaining it is entirely the technologist’s responsibility — and the return on that investment compounds with every assignment.

Practical format: Lessons learned entries work best as short, specific, actionable notes — not essays. “Always verify [library X] version before adding it as a dependency; v2+ has a breaking API change” is more useful than a paragraph about dependency management.

Collaboration Patterns

Beyond individual assignment retrospectives, a sustained collaboration benefits from a collaboration patterns file — a living record of validated observations about how the specific human-agent pair works together.

Unlike lessons learned (which are assignment-specific and technology-specific), collaboration patterns are portable — they describe the dynamic between this human and this agent across all work. The reinforcement loop is: observe → record → retrieve → apply → observe outcome → update. See governance/collaboration-patterns.md.

Testing Standards

Testing in LLM-assisted development follows the same professional standards as any software project — with heightened importance, because LLM Agents can introduce subtle regressions that are not immediately visible and may not surface until integration.

Priority order:

1. Integration tests — first priority for all new and existing codebases

   • Must cover all golden path / must-always-work flows at 95%+
   • If they don’t exist, create them before any refactoring begins
   • These are the primary safety net for LLM-generated changes
   • Use as use cases, then as integration tests, then as automated regression tests

2. Unit tests — second priority

   • Coverage target: 80%+
   • Focus on logic boundaries, edge cases, and error paths

3. Extended testing (instruct the agent to execute):

   • Log output validation (log file contains expected content)
   • Smoke tests for artifact launch (basic operations function)
   • Automated integration replays via REST, gRPC, IPC, or equivalent

On refactoring: LLM Agents struggle with refactoring existing codebases. Without sufficient integration test coverage, LLM-generated refactoring will produce unseen regressions. Do not begin a refactoring assignment until the 95% golden path threshold is met. If it isn’t met, creating those tests is the first assignment.

Testing above and beyond: Instruct the agent to propose additional test scenarios beyond what was specified. Manual testing by the technologist and regular architectural reviews — especially early in a project — catch structural issues before they become expensive to fix.

Cost of Operations

Understanding the true cost structure of LLM-assisted development is essential to making sound decisions about when structure pays and when shortcuts look cheap but aren’t.

The One-Shot Cost Model

A one-shot solution — generated from a single prompt with no governance, planning, or iteration — appears inexpensive: minimal time, minimal effort, something running quickly. The true costs appear after delivery.

Hidden costs of one-shot outputs:

Unserviceability. Code that cannot be maintained, extended, or handed off to another developer is not an asset. It is a liability that accumulates carrying cost until it is rewritten or abandoned. The question is not whether that cost arrives — it is when.

The “fix my vibe code” ecosystem. A market has emerged specifically around repairing one-shot outputs that didn’t meet production needs. This is a market signal worth reading: if fixing unplanned code were cheaper than planning it in the first place, the market wouldn’t exist. Paying for repair after the fact is consistently more expensive than investing in structure before it.

Service vs. product. A one-shot output may be acceptable as a one-time service — a script run once, a report generated once, a calculation done once. It is not a product. It cannot be versioned, updated, handed off, or extended to support new requirements. Treating a one-shot output as a product creates compounding maintenance debt from day one.

“Just one more feature.” Adding a feature to an unplanned codebase is disproportionately expensive. Without architecture, without tests, without design — every addition risks destabilizing existing behavior. The cost of “one little feature” is not linear. It scales with the structural entropy of the underlying code. The more one-shot additions that have accumulated, the higher the cost of each subsequent one.

Where Structure Pays

The upfront cost of a structured approach is real. The compounding cost of skipping it is larger. The tradeoff becomes clearer with each assignment.

Context and Session Continuity

LLM Agents have no persistent memory between sessions. Every new session begins with an empty context window. Managing this boundary deliberately is what separates professional LLM Agent use from sessions that start cold every time.

Memory Taxonomy

Agent memory maps to four types. Understanding them helps you reason about what the agent “knows” at any point and what must be explicitly loaded:

Working memory is bounded by the model’s context window. All other types persist in files and must be loaded at session start.

Session Context

The session-context.md file is the compression mechanism for cross-session continuity. It captures what was completed, the active implementation plan status, deferred scope, and open questions — enough for a new session to resume without re-reading full conversation history.

At the end of any significant session, update session-context.md. At the start of the next, load it before anything else. This makes context window limits manageable: instead of loading everything, the next session loads only the compressed summary of what matters now.

Context Window Management

Context windows are finite. Signs the window is becoming a constraint: the agent references earlier content with reduced accuracy, or restates things already established.

Practical responses:

• Start a new session and load session-context.md to resume cleanly
• Load governance selectively at session start — not exhaustively; most sessions need only governance relevant to the current task
• For long design sessions with heavy governance loads, prefer a more capable model

Advanced: Reusable Framework vs. Team/Org Isolation

The practices described in this article form a reusable framework — portable, technology-agnostic, and applicable to any LLM Agent collaboration regardless of language, stack, or team size.

In practice, teams and organizations go further: they maintain a team or org instance of the framework, capturing their specific practices, accumulated lessons, and assignment history. This instance lives separately from any individual project or assignment repository.

The distinction:

Why isolation matters. Mixing governance and lessons-learned content with assignment code creates a maintenance problem and, potentially, a confidentiality problem. The governance repo informs the work; it does not contain the work. Keeping them separate means governance can be shared, versioned, and reused independently of any specific project.

Portability. A new team member, a new project, or a new organization can adopt the reusable framework without inheriting the team’s specific history. They build their own instance over time — accumulating their own lessons, encoded in their own governance overlay — while benefiting from the structural foundation the framework provides.

Team/org governance captures:

• Org-specific coding standards and architectural patterns
• Accumulated lessons learned across all projects
• Assignment templates tuned to the team’s workflow
• Model selection guidance specific to the team’s tooling
• Language and technology overlays maintained collaboratively

This is how institutional knowledge survives beyond individual contributors and survives beyond individual projects.

Deployment profiles. The framework ships with three deployment profiles:

Each layer can extend or replace the one below it without modifying the shared base. The profile and override mechanism is covered in detail in the companion enterprise article.

Tooling. A companion tooling repository provides the operational layer:

• scaffold-project — generates the governance directory structure for a new project from the chosen profile
• init-profile — initializes a team or personal instance from the infrastructure base
• context-hydration — loads the appropriate governance files into the agent’s working context at session start

These tools eliminate the manual overhead of assembling governance per session. Full coverage in the enterprise article.

The repo accompanying this article provides a scaffolded starting point for both layers. See the repo README for the structure and how to adapt it.

Conclusion

Effective LLM Agent collaboration is not about finding the best prompt. It is about building a system around the collaboration — one that governs behavior, structures work, captures knowledge, and continuously improves.

The principles are familiar to any experienced software team:

• Govern before you execute
• Plan before you implement
• Review before you accept
• Test before you ship
• Learn after every assignment

Applied consistently, these practices make LLM Agent collaboration more productive, more predictable, and significantly less expensive than the alternative.

See also:

• Introduction to Using LLM Agents: From Concepts to Actions
• LLM Agent Collaboration at Scale: Team Deployment and Governance

See also: the companion overview article — Introduction to Using LLM Agents: From Concepts to Actions