Agentic Development

How to build a context-centric software factory

A software factory is an engineering operating model where coding agents perform a growing share of recurring software delivery work through reusable workflows, while humans define intent, set quality standards, review critical changes, and improve the system behind the work. It is not simply a coll

MMichael SwindellSeptember 4, 202620 min read

A software factory is an engineering operating model where coding agents perform a growing share of recurring software delivery work through reusable workflows, while humans define intent, set quality standards, review critical changes, and improve the system behind the work. It is not simply a collection of scripts or disconnected automations. A durable factory combines shared context, clear acceptance criteria, verification, observability, and feedback loops that improve over time. Teams building this model need a project control plane that keeps issues, tests, agent actions, and review decisions connected. Levr provides one approach for coordinating humans and coding agents around the same live project context.

At a Glance

A practical framework for moving from isolated AI assistance to reliable agentic development workflows.

Start with context: Define standards, workflows, and acceptance criteria before automating execution.
Build reusable skills: Capture what good work looks like in focused, versioned instructions that agents can apply repeatedly.
Turn skills into loops: Schedule or trigger recurring work, collect evidence, and use results to improve future runs.
Verify outputs: Pair agent instructions with deterministic checks, targeted evaluators, CI/CD gates, and human approval where needed.
Measure the system: Track work, test results, review signals, and ownership so increased output does not become unmanaged output.

What is a software factory in agentic development?

A software factory is a system of repeatable, context-aware workflows in which coding agents carry out software tasks and humans improve the rules, checks, and operating environment. Its defining feature is compounding improvement: work produces feedback that strengthens the next run instead of remaining isolated automation.

A factory differs from using an AI coding tool for one-off tasks. An individual developer might ask an agent to generate a component, review a pull request, or update a dependency. Those uses can be valuable, but they do not automatically create organizational learning.

A factory begins when a team turns recurring work into shared operating knowledge. That knowledge can include:

Implementation standards for a repository, service, or directory.
Acceptance criteria for a product change.
Rules for code review and merge readiness.
Test requirements and expected evidence.
Permissions, approved tools, and execution boundaries.
Feedback from prior failures, review comments, and production issues.

The result is a shift in where engineering effort goes. Instead of spending all available capacity directly writing application code, teams increasingly spend time shaping work, reviewing exceptions, maintaining workflows, and strengthening the controls that agents operate within.

Why do disconnected automations fail to compound?

Disconnected automations fail because each one carries its own hidden assumptions, instructions, access, and maintenance burden. They may improve a narrow task, but they do not share standards or learn from outcomes. A factory connects those workflows through common context, evaluation, and observability.

It is common for early adoption to look fragmented. One engineer has automated dependency upgrades. Another uses a code-review bot. A third has a local prompt that produces reliable tests. These are useful local optimizations, but they create several problems at scale:

Duplicated knowledge: Teams solve the same problem in multiple prompts, files, or repositories.
Drift: A workflow may reflect an old architecture, policy, or coding convention.
Inconsistent quality: Similar changes receive different standards depending on who launched the agent.
Poor discoverability: People cannot easily identify the correct workflow for a task.
Limited feedback: Failures and review findings do not automatically improve the instruction set.

The alternative is not a massive central automation program. It is a shared system for identifying important context, assigning ownership, versioning it, and making it available where the work happens.

How should teams move from skills to loops to a factory?

Teams should progress gradually: document and test a skill, reuse it in relevant work, automate it as a loop once it is reliable, then connect multiple loops through shared project context and verification. This reduces risk and creates a foundation for higher autonomy.

1. Define a skill

A skill is a focused unit of operational knowledge for an agent. It may describe a workflow, a policy, a review standard, a tool sequence, or a domain-specific definition of correctness.

For example, a frontend accessibility skill might specify that changed interactive components need appropriate labels, keyboard behavior, semantic markup, and relevant tests. A backend skill might instead focus on error handling, reuse of existing modules, and safe treatment of data boundaries.

The key is specificity. Generic guidance such as “write clean code” does not give an agent enough usable direction. Good skills state what matters, where it applies, and how success can be checked.

2. Apply the skill manually first

Before scheduling a workflow, run it on a small number of representative tasks. Check whether the instructions produce useful outcomes, whether they miss important cases, and whether they create noise.

This step also reveals ambiguity. If reviewers repeatedly explain a standard that is not represented in the skill, the skill is incomplete. If the agent produces irrelevant findings, the scope may be too broad.

3. Add verification

Instructions alone are not enforcement. A coding agent can misunderstand, skip, or misapply written guidance. Pair the skill with checks that test whether the expected outcome occurred.

Verification can be deterministic, such as a lint rule or test suite, or evaluative, such as a focused model-based check for a nuanced standard. For risk management, the NIST AI Risk Management Framework emphasizes governing, mapping, measuring, and managing AI-related risks. In an engineering workflow, those principles translate into explicit boundaries, measurable evidence, and documented responses when a process fails.

4. Turn the workflow into a loop

A loop runs a skill recurrently, on a schedule or trigger, then captures outcomes that inform future improvements. Examples include dependency maintenance, flaky-test detection, architectural checks, test-coverage reviews, and recurring codebase hygiene work.

A useful loop has four parts:

Input: The task context, repository state, issue, pull request, or scheduled target.
Execution: The agent workflow and approved tools.
Verification: Tests, policy checks, targeted evaluations, or review gates.
Feedback: Logs and results that expose missing context, false positives, or new rules.

5. Coordinate loops through a control plane

When multiple agents and workflows operate across the same projects, task state cannot live only in prompts, chat histories, or local folders. Teams need a shared source of truth for work definitions, dependencies, evidence, and approvals.

One way to structure this in Levr is to define an issue in natural language, attach acceptance criteria, let an agent work the task, require automated verification, and hold human review at the appropriate gate. The agent, tests, pull request, and resulting issue state remain connected rather than being spread across unrelated systems.

Give agents context they can act on safely.

Levr connects coding agents to shared issues, acceptance criteria, test evidence, workflow gates, and an attributed activity trail so teams can increase autonomy without losing project visibility.

Explore agent-first project workflows

Why must context engineering come before automation?

Context engineering comes first because automation only amplifies the quality of the instructions, standards, and constraints available to an agent. Without a usable definition of correct work, teams may produce more code and more pull requests while preserving the same ambiguity, review load, and defects.

Context is more than a prompt. It is the accumulated operating manual that tells an agent how to behave in a particular environment. It can include repository conventions, architectural constraints, accepted dependencies, product language, security expectations, code ownership, and test practices.

Consider an agent asked to implement a new settings screen. If it receives only a product request, it may produce a plausible result. But it may not know the preferred component library, accessibility conventions, copy style, analytics requirements, test pattern, or API boundary. Those omissions create review work later.

A context-centric workflow shifts that knowledge earlier in the process. The same standards used in review should also be available during implementation. This reduces preventable rework and makes agent behavior more consistent across tasks.

Context should also be scoped. A broad codebase-wide rule may be appropriate for security or formatting, while a specialized rule belongs only in a particular service or directory. Applying frontend concerns to a backend change wastes time and creates irrelevant output. Targeted context improves both accuracy and cost control.

What makes agentic code review effective at scale?

Agentic code review scales when it uses specific, reusable standards tied to the files and systems being changed, then feeds review outcomes back into those standards. Generic review prompts can catch obvious issues, but they often plateau because they lack repository-specific knowledge and produce unnecessary noise.

Many teams begin with a general-purpose reviewer because setup is easy. That can provide an immediate boost, including earlier detection of basic defects. The limitation appears when teams expect the tool to replace more of the review process.

General review systems struggle to answer questions that depend on local context:

Which patterns are approved in this service?
What must be true before a change can merge?
Which files require accessibility checks?
Which dependencies are allowed or prohibited?
Which test cases demonstrate the stated acceptance criteria?

The practical answer is to create focused review lenses or skills. Each lens can apply to a file pattern, component type, service boundary, or category of change. For example, a frontend lens may inspect semantic structure and accessibility requirements, while a data-processing lens checks resilience and handling of edge cases.

GitHub’s pull request collaboration documentation describes review as a structured process for discussing and approving changes. Coding agents can participate in that process, but high autonomy depends on giving them the same relevant standards that experienced human reviewers use.

The review loop should also improve itself. Repeated review comments are evidence. They may identify a missing standard, a confusing instruction, a verifier gap, or a problem that should have been caught during development rather than at the pull request stage.

How do verifiers and evals increase trust in coding agents?

Verifiers and evaluations increase trust by testing whether an agent actually met a defined standard instead of assuming it followed instructions. They create evidence for agent actions, catch deviations early, and help teams decide where more autonomy is justified.

A verifier is a focused check linked to a requirement. It might inspect changed files, test a structural property, validate expected output, or assess a narrow quality condition. Some verifiers are deterministic. Others use an evaluator model to judge a constrained question.

For example, an accessibility requirement can produce several types of verification:

A static check for required attributes or component usage.
A test that validates keyboard behavior.
A focused evaluator that inspects whether a changed interaction is understandable and consistent with local guidelines.

The goal is not to make every check model-based. Deterministic checks remain useful because they are fast, repeatable, and clear. Model-based evaluation is best applied where judgment is needed and where the question can be narrowly framed.

Good evaluators are specific. Asking a model to decide whether code is “good” invites broad and inconsistent output. Asking whether a changed React component has required accessibility information is a smaller task with clearer evidence and a more stable decision boundary.

Teams should treat verifier results as feedback for both the code and the workflow. A missed problem may require a better skill, a stronger test, a narrower tool permission, or a human checkpoint. An evaluator that generates constant false positives needs refinement before it becomes a gate.

What unexpected benefits can a software factory create?

A software factory can create quality improvements and broader participation, not only faster feature delivery. When agents increase execution capacity, teams can address consistency, maintenance, and small improvements that often remain in backlogs, while people can contribute outside traditional role boundaries.

Feature velocity is the most obvious expected result. When coding agents can work on well-defined tasks, the volume of changes can rise quickly. But more capacity does not have to become more product scope.

Teams can direct some of that capacity toward work that is usually deferred:

Correcting inconsistent copy and brand language.
Removing outdated interface details.
Improving design consistency across screens.
Repairing flaky tests.
Updating dependencies and documentation.
Finding gaps between acceptance criteria and test coverage.

The second benefit is role flexibility. A designer can propose and validate focused interface refinements. A product manager can help shape detailed acceptance criteria. A go-to-market team member can improve a marketing surface. Engineering still owns appropriate review and safeguards, but agents can reduce the handoff friction that previously made smaller contributions impractical.

This does not mean every person should directly change every system. It means work can be organized around clear intent and verifiable outcomes rather than only around the availability of a particular specialist.

How do you keep a software factory observable and secure?

Keep a software factory observable and secure by centralizing task state, limiting permissions, recording actions, capturing execution logs, and requiring verification before work reaches sensitive stages. Agent autonomy should expand only when teams can explain what happened, why it happened, and how it was checked.

Security and operational visibility improve when agentic work moves from ad hoc local setups into defined workflows. The goal is not centralization for its own sake. It is the ability to understand which tools run, what information they access, what changes they make, and what evidence supports those changes.

Use this checklist when establishing controls:

Inventory skills and tools: Identify the instructions, Model Context Protocol tools, plugins, and repositories that agents use.
Find duplicates and stale context: Consolidate overlapping guidance and update standards that no longer match the codebase.
Apply least privilege: Limit repository, environment, network, and write access to what a workflow requires.
Separate execution environments: Run untrusted or higher-risk work in controlled environments where appropriate.
Require attributable activity: Record whether a human or agent took an action, along with relevant timestamps and artifacts.
Link tests to intent: Connect test results to acceptance criteria, issues, pull requests, and commits.
Define escalation paths: Decide when an agent can continue, when it should ask for input, and when a human must approve.

Levr supports this model by treating issues, tests, automation runs, pull requests, and human or agent actions as related project objects. Its agent-first features include structured acceptance criteria, workflow gates, native testing, shared context, and attributed history across mixed agent and human workflows.

See Every Skill, Loop, and Verifier Run

Not every task deserves the same amount of agent autonomy. The Levr Dashboard shows what permission level each agent is running under, which changes are auto-approved versus gated, and where human review is still required — so autonomy scales with actual risk, not just how capable the model claims to be.

Agentic Software Development | Control Plane | Manual & Automatic Verification Issue Tracking |Levr

Skills and loops do the work; Levr's dashboard shows you the evidence.

What is a practical first software factory workflow?

The best first software factory workflow is a narrow, recurring task with clear inputs, observable outputs, and a low-risk rollback path. Dependency maintenance, flaky-test investigation, codebase consistency checks, and targeted review automation are strong starting points because they can be measured and refined.

Avoid beginning with a broad instruction such as “autonomously build features.” That combines too many unknowns: unclear specifications, complex dependencies, uncertain permissions, weak verification, and vague approval boundaries.

Instead, choose a workflow with a known pain point. A flaky-test maintenance loop is a good example:

Define the target: Identify what counts as a flaky test and which repositories are in scope.
Capture the context: Provide testing conventions, relevant CI/CD logs, ownership information, and expected remediation patterns.
Run with limited permissions: Let the agent analyze failures and propose or create a scoped change.
Verify results: Require repeated successful runs or other objective evidence before marking work complete.
Review exceptions: Route ambiguous failures or larger refactors to a human owner.
Improve the skill: Add recurring patterns and review findings back into the workflow guidance.

Once that loop is useful, expand carefully. The same foundational context may support related workflows, such as test-coverage assessment, recurring architecture reviews, or dependency upgrade proposals. The factory emerges from connected, improved loops rather than a single switch to full autonomy.

Technical Deep Dive FAQ

What is the difference between a software factory and automation?

Automation performs a repeatable action, such as running a test suite, creating a pull request, or updating a dependency. A software factory is a broader operating model that connects many automated and agent-driven workflows through shared context, standards, verification, feedback, and visibility. Automation can remain static and isolated. A factory is designed to learn from its runs, refine how work is performed, and make task state and quality evidence visible across the engineering organization.

What is context engineering for coding agents?

Context engineering is the practice of organizing the information a coding agent needs to make correct decisions in a specific environment. It includes technical standards, repository conventions, product requirements, acceptance criteria, workflow rules, tool boundaries, and lessons from historical work. The purpose is not to create a long generic prompt. It is to supply targeted, current, reusable context at the moment a task requires it, so agents can work with less ambiguity and fewer preventable review cycles.

How do you write a useful agent skill?

Write an agent skill as a focused operational contract. State the purpose, scope, applicable files or systems, required inputs, concrete rules, expected outputs, and verification criteria. Include examples only when they clarify an edge case or preferred pattern. Avoid broad phrases such as “use best practices,” because they require the agent to guess what matters locally. Start with one job, such as reviewing API error handling or validating accessibility changes, then improve the skill using real execution and review feedback.

Should skills be shared across repositories?

Some skills should be shared, especially organization-wide standards for security, coding conventions, brand language, or review practices. Others should remain scoped to a repository, service, directory, or team because architecture and ownership differ. A practical approach is to maintain a small set of common baseline skills and layer targeted skills on top. Versioning and inventory matter because duplicated or stale skills create inconsistent agent behavior and make it difficult to determine which definition of correct work is authoritative.

What should an agent verifier check?

An agent verifier should check a narrow, meaningful requirement that can be tied to evidence. Examples include whether tests passed, whether a changed component meets an accessibility rule, whether a migration follows an approved pattern, or whether a pull request includes the requested artifacts. Use deterministic checks where possible because they are fast and repeatable. Use model-based evaluation when the requirement needs judgment, but keep the question specific. Broad quality judgments produce less reliable and less actionable results.

Can coding agents review their own pull requests?

Coding agents can review their own pull requests, but self-review should not be the only quality control for important changes. It works best when the agent applies explicit standards, runs tests, and produces evidence that another workflow or person can inspect. Independent checks reduce the risk of repeating the same mistaken assumption used during implementation. For higher-risk changes, combine self-review with targeted verifiers, a separate review agent using different instructions, CI/CD gates, and human approval before merge.

How do teams avoid agentic code review noise?

Teams reduce review noise by using focused review skills that apply only to relevant files, components, and change types. A backend reliability lens should not comment on frontend layout conventions, and an accessibility lens should not inspect unrelated infrastructure files. Track findings over time to identify repetitive false positives, unclear rules, and rules that belong in deterministic checks instead. A useful review system prioritizes actionable findings, links each finding to a defined standard, and feeds recurring results back into the underlying context.

What metrics matter in a software factory?

Useful software factory metrics connect throughput with quality and operational health. Track completed work, blocked work, cycle time, test pass trends, coverage against acceptance criteria, review findings, failed automation runs, and the rate of human intervention. Also track who performed actions, whether human or agent, so responsibility remains clear. Avoid treating pull request volume alone as success. More changes are valuable only when the system can verify them, maintain them, and keep product and operational quality moving in the right direction.

How should an engineering manager introduce higher agent autonomy?

An engineering manager should introduce higher autonomy in stages. Start with a narrow workflow, documented standards, restricted permissions, and visible output. Review the agent’s behavior and verifier results, then improve the context before expanding scope. Define non-negotiable gates for tests, security-sensitive actions, production changes, and final approval. As reliability improves, allow the workflow to act on a larger set of tasks. This approach treats autonomy as an earned operational property, not a permanent configuration choice.

Can a software factory improve existing code quality?

Yes. Extra agent capacity can be directed toward maintenance work that often loses priority to feature delivery. Teams can build loops for consistency fixes, copy updates, UI cleanup, dependency upgrades, flaky-test repair, and architecture checks. The important requirement is a clear definition of the desired standard and a way to verify improvements. Without those, a maintenance agent may create large volumes of low-value changes. With targeted skills and review gates, it can steadily reduce accumulated quality debt.

How does Model Context Protocol fit into a software factory?

Model Context Protocol, or MCP, provides a standard way for agents to connect to tools and systems. In a software factory, MCP can help agents access project information, testing capabilities, repositories, and other approved services. However, MCP connectivity alone is not a factory. Teams still need scoped permissions, reliable context, workflow state, logging, verification, and governance. Treat each connected tool as part of the operational surface that must be inventoried, reviewed, and constrained according to the task being performed.

How can Levr support an agentic software factory?

Levr can support an agentic software factory by giving coding agents and humans a shared control plane for projects, issues, acceptance criteria, tests, workflow states, and review gates. Agents can work against the same live objects used by the team, while automation runs and results remain connected to the relevant work. Levr also supports mixed agent environments through MCP, so teams can coordinate Claude Code, Cursor, Codex, Copilot, and other compatible agents without separating planning, execution, verification, and accountability.

Key Takeaways

A software factory is not defined by the number of agents or pull requests it produces. It is defined by whether the organization can turn agent execution into repeatable, observable, and improving software delivery.

Build the operating system for agentic work before expanding autonomy.

Context first: Document what correct work looks like before asking agents to automate it.
Skills become assets: Reusable instructions should be versioned, scoped, discoverable, and continuously improved.
Verification is essential: Pair skills with tests, evaluators, policy checks, and review gates.
Loops create compounding value: Capture real outcomes and use them to improve the next execution.
Visibility preserves trust: Keep tasks, actions, evidence, and approvals connected in a shared control plane.

The practical path is incremental: build one useful workflow, measure it, improve it, and then connect it to the next.