Jacques Murray — Notes & Projects

From Prompts to Autonomous Systems: Practical Agent Workflows in Daily Engineering

· AI· Development

Most engineers begin their interaction with large language models inside an open chat window. You type a prompt into an interface, paste an excerpt of code, wait for a stream of generated tokens, copy the suggested fix back into your editor, and run your compiler to see if the changes function. For small utility scripts or localized function refactoring, this manual conversational cycle feels like an acceleration.

Once your requirements expand to multi-file refactoring, systemic codebase migrations, or end-to-end bug investigations, conversational chat interfaces collapse under their own architectural weight. The user becomes a manual data conduit, perpetually copying terminal outputs and compiler stack traces back into a text box. More critically, the chat session accumulates hundreds of turns of discarded attempts, stale hypotheses, and rambling conversational pleasantries that dilute the model’s attention.

In my recent book, Prompt Engineering for AI LLMs: A Beginner’s Guide (as detailed in our announcement and core prediction mechanics breakdown ), I established the core mechanical reality of transformer models: an LLM computes probability distributions over vocabulary tokens based on the exact input sequence provided. The path toward production-grade reliability requires shifting focus away from conversational prompting. Sustainable software engineering demands building autonomous agent architectures: structured systems governed by the Model Context Protocol (MCP), isolated multi-agent pods, persistent memory graphs, and deterministic compiler gates.

The Chat Window Ceiling: Context Exhaustion and Attention Dilution

The fundamental constraint of conversational interfaces centers on attention allocation. A transformer context window functions as a shared memory canvas where every single token attends to every other token through learned weight projections. While modern models boast context ceilings of 200,000 to one million tokens, attention density degrades across massive context spans.

Long conversational sessions introduce three distinct points of failure:

  1. Context Pollution: Early, incorrect code suggestions remain permanently embedded in the conversation history. Because subsequent generation steps attend to earlier failures, the sampler continues assigning probability mass to previously introduced anti-patterns and stale assumptions.
  2. The “Lost in the Middle” Degradation: Attention weight concentrates at the absolute start and the immediate end of the token stream. Crucial architectural constraints placed midway through a sprawling, 50-turn conversation face severe attention attenuation, causing the model to quietly drop project rules.
  3. Manual Human Latency: The engineer functions as an expensive, error-prone bridge between the local filesystem, the compiler, the git log, and the model.

Production engineering requires resetting the context window between distinct operational phases. Autonomous agent systems maintain compact, task-focused contexts by delegating specific goals to transient execution subagents that terminate the moment their assigned subtask finishes.

Grounding via Tool-Use: The Model Context Protocol Architecture

Reliable code generation demands grounding model predictions strictly in local repository facts. Asking an LLM to debug a complex service based entirely on pre-trained parametric weights guarantees hallucinated function signatures and outdated dependency imports.

The industry standard for model grounding is the Model Context Protocol (MCP). MCP provides an open, JSON-RPC 2.0 based client-server architecture that standardizes how language models discover and invoke external tools on the developer’s workstation:

+-------------------------------------------------------------------------+
|                       MODEL CONTEXT PROTOCOL PIPELINE                   |
+-------------------------------------------------------------------------+
|                                                                         |
|  [ LLM Core Engine ]                                                    |
|         │                                                               |
|         │ Emits structured JSON tool call (e.g., read_file, run_tests)   |
|         ▼                                                               |
|  [ MCP Client Host / Agent Runtime ]                                    |
|         │                                                               |
|         │ Validates JSON schema against tool definitions                |
|         │ Routes request via local IPC / stdio socket                   |
|         ▼                                                               |
|  [ MCP Tool Server: Workspace File System & Git Runtime ]               |
|         │                                                               |
|         │ Executes deterministic local OS action                         |
|         │ Captures stdout, stderr, filesystem diffs                     |
|         ▼                                                               |
|  [ Structured Tool Result Returned to Model Context ]                   |
|                                                                         |
+-------------------------------------------------------------------------+

When an agent needs to understand a module boundary, it executes an explicit read_file or ast_search tool call. The tool returns the ground-truth bytes from disk directly into the context window. The model generates code against verified production interfaces.

To enforce deterministic tool interactions, tools declare strict JSON schemas that govern input structures:

{
  "name": "execute_codebase_refactor",
  "description": "Applies a unified structural patch across a single target file using precise boundary coordinates.",
  "parameters": {
    "type": "object",
    "required": ["TargetFile", "StartLine", "EndLine", "TargetContent", "ReplacementContent"],
    "properties": {
      "TargetFile": {
        "type": "string",
        "description": "The absolute filesystem path to the file undergoing modification."
      },
      "StartLine": { "type": "integer", "minimum": 1 },
      "EndLine": { "type": "integer", "minimum": 1 },
      "TargetContent": {
        "type": "string",
        "description": "The exact character sequence targeted for replacement."
      },
      "ReplacementContent": {
        "type": "string",
        "description": "The replacement source code block."
      }
    }
  }
}

By constraining inputs to exact line bounds and character sequences, the execution runtime rejects malformed or hallucinatory changes before any file on disk is touched.

Multi-Agent Specialization: Decoupling Roles into Isolated Contexts

A single engineer rarely writes the code, designs the visual layout, reviews the security perimeter, and drafts customer documentation in a single uninterrupted breath. Enterprise software succeeds because these responsibilities divide across distinct roles.

Attempting to force an LLM to act as systems architect, lead developer, security auditor, and technical writer within one unified prompt creates prompt congestion. Instructions for one discipline directly dilute the constraints of another.

Modern agent workflows utilize a Hub-and-Spoke Orchestration pattern:

                        +----------------------+
                        | AgentsOrchestrator   |
                        | (Project Manager)    |
                        +----------┬-----------+
                                   │
         ┌─────────────────┬───────┴─────────┬─────────────────┐
         ▼                 ▼                 ▼                 ▼
+-----------------+ +-------------+ +-----------------+ +-------------+
| System Architect| | Core Dev    | | Quality Auditor | | Tech Writer |
| Context: 8k     | | Context:12k | | Context: 10k    | | Context: 6k |
+-----------------+ +-------------+ +-----------------+ +-------------+
         │                 │                 │                 │
         └─────────────────┴───────┬─────────┴─────────────────┘
                                   │ Aggregates verified outputs
                                   ▼
                        +----------------------+
                        | Git Release Branch   |
                        +----------------------+

Under this pattern:

  1. The Lead Orchestrator maintains high-level project goals, task lists, and milestone verification. It never touches source files directly.
  2. The Specialized Subagent launches with an isolated context containing only the specific task instructions, the relevant files, and the tools required for that domain.
  3. Transient Execution: Once the subagent finishes its assignment (such as conducting an accessibility audit or generating unit tests), it emits a structured summary and terminates. Its 15,000 tokens of intermediate trial-and-error disappear, leaving the parent orchestrator’s context pristine and compact.

Long-Term Memory Graphs and Session Continuity

Autonomous agents must operate across extended multi-day initiatives without suffering amnesia between terminal reboots. Retaining full conversation logs indefinitely is economically prohibitive and architecturally disastrous due to attention degradation.

Production systems solve continuity through externalized memory architectures:

  • Architectural Decision Records (ADRs): Write all pivotal architectural agreements to structured markdown files inside the repository (or an integrated Obsidian Second Brain). When an agent initializes, it reads the current index of ADRs to inherit the team’s historical reasoning.
  • Semantic Vector Indexing: Codebases and operational notes are indexed into local vector databases. Agents execute semantic queries to pull relevant historical patterns on demand, retrieving precisely 500 tokens of pertinent context to preserve token efficiency.
  • Identity and Operational Manifests: A persistent operating manual (such as a root _CLAUDE.md or SYSTEM_RULES.md) defines project conventions, testing commands, folder structures, and forbidden dependencies. The runtime injects this brief manifest into every subagent invocation as foundational guidance.

This approach treats human engineering documentation as living memory. The agent consumes documented decisions when relevant and writes its own conclusions back into the project knowledge graph upon completion.

Deterministic Release Gates: Linters and Compilers Hold the Merge Key

The golden rule of autonomous software engineering is absolute: Language models propose changes; deterministic compilers and test suites decide reality.

An agent’s self-assessment possesses zero engineering authority. When a model reports, “I have verified the implementation and all tests pass,” that output represents an ungrounded string of tokens. Relying on an agent’s internal confidence guarantees subtle regressions in production.

Robust workflows embed agents within closed feedback loops bounded by external, deterministic release gates:

  1. Static Analysis & Linters: Following any code edit, the runtime automatically triggers linters (eslint, golangci-lint, ruff). Any lint violation returns to the agent as a tool error containing exact line numbers and diagnostic messages.
  2. Type Compilers: Strongly typed environments (tsc, cargo check, hugo, go build) act as ruthless verifiers. A proposed modification that fails compilation triggers an immediate rollback or a targeted remediation step. (For example, our command-line pipelines utilize the structured execution patterns covered in PowerShell for production automation to capture exit codes and failure streams systematically.)
  3. Automated Unit & Integration Suites: The agent remains in an active loop until the project test suite returns a clean exit code 0.
  4. Git Branch Isolation: Autonomous agents execute all experimental work inside isolated Git branches or detached worktrees. No change reaches the main branch without a clean build and a verified pull request artifact.
[ Agent Proposes Code Change ]
              │
              ▼
    [ Execute Compiler / Linter ] ──(Exit Code != 0)──► [ Feed Error Stack to Agent ]
              │                                                     │
        (Exit Code == 0)                                            │
              ▼                                                     ▼
     [ Run Automated Tests ] ───────(Failure)────────► [ Loop for Targeted Fix ]
              │
          (Passes)
              ▼
[ Git Commit & Open Pull Request ]

When deterministic software holds the gate, the probabilistic nature of language models is safely harnessed. The model contributes high-speed creative hypothesis generation, while the compiler enforces mathematical correctness.

The Five Pillars of Production-Grade Agentic Engineering

Transitioning your engineering practice from basic prompt experimentation to reliable autonomous systems requires establishing five foundational practices:

  1. Eliminate the Monolithic Session: Never conduct multi-step development inside an unmanaged, infinite chat window. Scope tasks into discrete stages and clear the context canvas between operations.
  2. Ground Every Action in Tool Reality: Interface your models with local repositories using standardized protocols like MCP. Force models to inspect real files and execute real tools.
  3. Specialize Agent Personas: Decompose complex software workflows into modular subagents with domain-specific vocabularies and strictly restricted tool permissions.
  4. Externalize System Memory: Store decisions, style guides, and operational learnings in structured Markdown repositories and semantic indexes to guarantee reliable knowledge retrieval.
  5. Enforce Deterministic Validation: Never permit an agent to approve its own work. Bind every autonomous workflow to external compilers, linters, and regression test suites with hard exit codes.

Language models amplify core software engineering fundamentals. The tighter your boundaries, the cleaner your architectural decoupling, and the more rigorous your automated verification gates, the more powerful your autonomous agent pipelines become.