進化型アーキテクチャにエージェント型フィットネス関数を追加

要点

• Evolutionary architecture makes the next change safer by turning architectural intent into continuous feedback rather than relying on periodic reviews, tribal memory, or late-stage governance.

• Deterministic fitness functions should remain the primary enforcement mechanism for measurable invariants such as dependency direction, contract shape, latency budgets, security posture, and policy checks.

• Agentic fitness functions add value when architectural risk is evidence-bound but judgement-heavy, such as boundary fidelity, semantic contract drift, workflow coupling, and stale ADR assumptions.

• A production-ready implementation separates deterministic gates from agentic advisory signals, scopes evidence to the change, applies versioned rubrics, returns structured verdicts, and escalates low-confidence or high-blast-radius outcomes to humans.

• The long-term value of agentic fitness functions is making architectural judgment more observable, calibratable, auditable, and easier to convert into deterministic guardrails when patterns repeat.

*This article was written by participants of the online InfoQ Certified Architect Program. It represents the capstone of their work, reflecting the cohort's collective learnings on the intersection of AI and modern software architecture.*

From Deterministic Rules to Architectural Judgment

Evolutionary architecture is built on a simple premise: architecture should not be treated as a fixed target state, but as a system of decisions that can evolve safely as business needs, technology choices, operating conditions, and team structures change. The discipline works when teams can make change continuously; as a result, business evolves, without allowing the architecture’s important characteristics to erode invisibly.

Fitness functions are the mechanism that makes this possible. They turn architectural intent into executable feedback. A dependency rule can protect package boundaries. A contract test can protect integration compatibility. A latency budget can protect performance. A security scan can protect policy compliance. These deterministic checks are essential because they make architectural governance continuous rather than episodic.

But not every architectural concern can be reduced to a rule, threshold, schema, or metric. A dependency rule can show that a service interaction changed; it cannot always tell whether the change represents intentional collaboration or accidental coupling.

A schema diff can prove that an API still parses; it cannot always judge whether the contract still expresses the right domain concept. A trace can reveal a new runtime path; it cannot always determine whether that path bypasses workflow ownership.

This is where agentic fitness functions become useful. They extend evolutionary architecture into the space between deterministic automation and manual architectural review.

An AI agent, calibrated against architecture decision records, ownership metadata, service boundaries, rubrics, and historical examples, can evaluate bounded evidence and return a structured judgment with score, confidence, rationale, and escalation guidance.

Agentic fitness functions do not replace deterministic fitness functions or architects. They add a governed judgment layer for concerns that are evidence-bound but not mechanically decidable. Used carefully, they help evolutionary architecture keep pace with modern delivery: smaller changes, faster feedback, AI-generated code, and architectural decisions that now surface inside pull requests, contract diffs, workflow traces, and agent-invoked actions.

The Ceiling of Deterministic Fitness Functions

Deterministic fitness functions are indispensable, but they only protect what can be reduced to a rule, a threshold, a schema, or an executable experiment. That still leaves a large class of architectural drift above the line of simple measurement.

A dependency rule can tell a team that a package imported another package. It cannot always determine whether the import represents intentional shared-kernel coupling, an accidental shortcut, or the first sign that a boundary is being hollowed out. A schema diff can show that an API still parses. It cannot always judge whether the new field preserves the semantic model or leaks a UI concern into a domain event.

These are not exotic edge cases. They are the normal way architecture decays: through individually reasonable changes that pass every written rule while slowly moving the implementation away from the intent the team believed it had protected. Historically, the answer was manual review. The problem is that manual review does not scale down to every pull request, every contract change, every workflow trace, or every agent-generated patch.

Figure 1. Deterministic fitness functions turn architectural intent into executable guardrails; agentic fitness functions extend that model into boundary intent, semantic drift, and other judgment-heavy architectural concerns. Source: author-created.

Agentic Fitness Functions: Calibrated Judgment, Not Oracles

An agentic fitness function is an architecture governance check whose evaluator is a calibrated AI agent, whose criteria are expressed as an analytic rubric, and whose output is a structured verdict with evidence, confidence, and rationale. It is not an oracle. It is not a replacement for deterministic checks. It is a way to make some formerly manual architectural judgments repeatable enough to run continuously and transparent enough to audit.

The distinction matters. A compiler, linter, schema validator, or SLO check should continue to block deployment when it detects a clear violation. An agentic fitness function should usually begin as an advisory signal. It becomes more influential only after calibration against prior human decisions demonstrates acceptable precision, recall, and variance. Even then, low confidence, judge disagreement, high blast radius, or ambiguous architectural trade-offs should escalate to a human reviewer.

The design principle is simple: use deterministic gates for objective invariants and agentic judges for evidence-bound interpretation. The agent should be given a small evidence pack, not the whole enterprise. It should evaluate a named concern, not "good architecture" in general. It should return a machine-readable result, not a conversational essay. And the rubric itself should be versioned and reviewed like code.

Figure 2. Agentic fitness functions sit beside deterministic gates. They consume a scoped evidence pack, produce structured verdicts, and escalate low-confidence outcomes instead of silently averaging them away. Source: author-created.

Production-Ready Agentic Fitness Function: Anatomy and ADK Reference Implementation

A production-ready agentic fitness function should be treated as an executable governance component, not as a free-form AI review. Its value comes from a clear execution boundary: it receives a specific architectural concern, evaluates bounded evidence, applies a named rubric, and emits a structured verdict that can be stored, trended, and audited.

The basic anatomy has four parts. First, there is a fitness-function intent: the architectural concern the team wants to protect, such as boundary fidelity, semantic contract integrity, or ADR drift. Second, there is an evidence contract: the limited set of artifacts the judge is allowed to inspect, such as the PR diff, changed API specification, relevant ADRs, ownership metadata, service catalog entry, deterministic-check output, or trace window. Third, there is an agentic judge: a calibrated AI agent that applies an analytic rubric to the evidence. Fourth, there is a structured verdict: a machine-readable result containing score, confidence, violated criteria, rationale, evidence references, and recommended action.

To make this pattern concrete, we created a small ADK-based reference implementation: agentic-fitness-functions.

The implementation models an agentic fitness function as a pipeline. A change event, such as a pull request or contract diff, is converted into a scoped evidence pack. Deterministic checks run first and remain responsible for objective constraints such as dependency rules, schema validation, policy checks, and threshold-based gates. The ADK-based architecture judge then evaluates the remaining judgment-heavy concerns using a rubric and produces a structured verdict.

The important design choice is separation of responsibility. The framework does not ask the agent to replace deterministic fitness functions. Instead, it places the agent beside them, where it can evaluate concerns that are evidence-bound but not easily reducible to a fixed rule. For example, a dependency rule may detect that a new service interaction exists; the agentic judge can assess whether that interaction is intentional collaboration, accidental coupling, or a boundary-fidelity risk. A schema diff may show that an API remains backward compatible; the agent can assess whether the contract still preserves domain meaning.

Figure 3. Use deterministic fitness functions when the concern can be expressed as a rule or threshold. Use agentic fitness functions when a calibrated rubric can be applied consistently to bounded evidence. Keep a true ambiguity manual. Source: author-created.

A Minimal Structured Verdict

{
  "fitness_function": "checkout-boundary-fidelity",
  "rubric_version": "2026.07.01",
  "score": 0.68,
  "confidence": 0.74,
  "decision": "advisory_warn",
  "violated_criteria": [ "semantic coupling"],
  "evidence": ["ADR-014", "OrderEvent.diff", "PaymentSession DTO"],
  "recommended_action": "Move PaymentSession behind a checkout-owned adapter or create an explicit shared-kernel ADR.",
  "deterministic_rule_candidate": "Disallow public events from exporting internal payment-state DTOs."
}

Calibration and Controls

Agentic fitness functions require calibration before they influence delivery. A practical calibration set includes 20 to 50 prior changes that the architecture community has already classified as acceptable, risky, or unacceptable. Run the judge against those examples and tune the rubric until false positives, false negatives, and variance are understood. Re-run the set whenever the model, prompt, rubric, tool chain, or evidence contract changes.

Do not hide uncertainty. Confidence is part of the verdict. Disagreement between two judges, large variance across repeated runs, or missing evidence should escalate to a person. Averaging away disagreement is dangerous because disagreement is often the signal that the architectural trade-off is real.

The system also needs controls against reward hacking and prompt injection. The agent should ignore instructions found in code comments, PR descriptions, logs, or generated files unless those artifacts are explicitly listed as evidence. The judge model should be isolated from the agent that produced the code where possible. Rubric changes should go through pull request review, and verdict data should be retained for audit, trend analysis, and recalibration.

Three Examples of Agentic Fitness Functions

The following examples show where agentic AI is useful. Each example keeps a deterministic control plane wherever possible and uses the agent only for the interpretive layer that previously required a senior reviewer.

Boundary-Fidelity Reviewer

Deterministic dependency rules can detect obvious boundary violations, such as one package importing a forbidden package. The harder problem is identifying whether a change weakens the ownership of a business capability without breaking any explicit dependency rule. Architectural erosion often appears as shared abstractions, leaked implementation details, duplicated business logic, or increasing coordination between services rather than as illegal imports.

An agentic Boundary-Fidelity Reviewer evaluates the pull request against ADRs, service ownership metadata, package graphs, CODEOWNERS, and repository context to reason about architectural intent. It looks for semantic coupling, hidden coordination paths, shared state abstractions, and knowledge crossing bounded contexts that the architecture has not explicitly sanctioned.

The verdict includes a boundary-fidelity score, evidence references, confidence level, and a recommended action. Rather than replacing deterministic dependency analysis, it complements it by identifying subtle boundary erosion early and directing architectural attention where human judgment is most valuable.

Semantic Contract Evaluator

Schema validators ensure that APIs and events remain structurally compatible, but compatibility does not guarantee good architectural boundaries. A contract may remain backward compatible while gradually exposing internal identifiers, infrastructure concerns, UI-specific fields, or provider implementation details that unnecessarily couple consumers to the service.

An agentic Semantic Contract Evaluator reviews OpenAPI or AsyncAPI diffs, sample payloads, consumer contracts, ADRs, and API design guidance to assess whether the contract remains consumer-focused, semantically cohesive, and expressed in the domain language. It reasons about the meaning of the interface rather than only its structure.

The verdict includes a semantic cohesion score, coupling risk assessment, evidence references, confidence level, and a recommended action. Deterministic validators continue to enforce schema compatibility, while the agent provides architectural interpretation about meaning, abstraction, and long-term coupling risk.

ADR Drift Monitor

Architectural decisions remain valid only while the assumptions behind them continue to hold. An ADR may justify synchronous communication because traffic is low, accept a shared database as temporary, or tolerate a particular trade-off based on organizational or operational constraints. As systems evolve, those assumptions can quietly become invalid even though the implementation still conforms to the documented decision.

An agentic ADR Drift Monitor periodically compares ADR assumptions against operational metrics, incidents, cost trends, dependency graphs, deployment patterns, and ownership changes. Instead of evaluating code changes, it evaluates whether architectural decisions still match the current reality and identifies evidence of architectural drift.

The verdict identifies the original assumption, the evidence that has changed, the resulting architectural risk, confidence level, and a recommended review path. It does not fail builds; instead, it proactively prompts architects to revisit decisions whose original rationale may no longer be valid.

Practical Guidelines

• Keep hard gates deterministic. Use deterministic checks for conditions that can be expressed as rules, schemas, thresholds, policies, or repeatable experiments. Do not replace reliable gates with probabilistic judgment.

• Start advisory. Run every new agentic fitness function in advisory mode until calibration proves that its signal is stable, useful, and worth acting on.

• Scope evidence to the change. Provide the agent with the PR diff, touched contracts, local dependency graph, relevant ADRs, and a small trace window rather than an entire codebase.

• Use analytic rubrics. Break judgment into named criteria. A single architecture quality score is not actionable; a criterion-level verdict is.

• Preserve human escalation. Low confidence, judge disagreement, high blast radius, or ambiguous trade-offs should route to a human reviewer immediately.

• Promote stable findings. When agentic findings recur, and the team agrees they represent real violations, convert them into a named rubric criterion or a deterministic rule.

• Version the judge. Treat prompts, rubrics, calibration sets, model versions, and tool definitions as governed artifacts.

• Audit the evidence trail. Store the evidence references, verdict, confidence, rationale, and follow-up action so the team can review the decision later.

Toward Governed Architectural Judgment

Evolutionary architecture is not about predicting the final form of a system. It is about making the next meaningful change safe, observable, reversible, and aligned with the architectural characteristics the organization values. Fitness functions are the core mechanism because they turn governance from episodic opinion into continuous feedback.

Agentic AI extends that mechanism into a previously manual space. It can review bounded evidence, apply a calibrated rubric, and return a structured judgment about concerns that deterministic rules do not fully capture: semantic drift, boundary fidelity, resilience interpretation, and stale architectural assumptions. That is useful precisely because these judgments already exist in architecture practice. The agent does not invent them; it makes them repeatable enough to observe and disciplined enough to improve.

The safe pattern is conservative. Keep deterministic gates as gates. Use agentic checks as calibrated signals. Escalate uncertainty. Version the rubrics. Recalibrate over time. Promote repeated findings into deterministic checks when possible. Used this way, agentic fitness functions become a pragmatic extension of automated software governance: judgment as code, but with the humility that judgment still needs evidence, context, and accountability.

References

• Neal Ford, Rebecca Parsons, Patrick Kua, and Pramod Sadalage, Building Evolutionary Architectures: Automated Software Governance, 2nd ed. O'Reilly, 2022.

• Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.

• Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.

• Sam Newman, Building Microservices, 2nd ed. O'Reilly, 2021.

• Martin Fowler, "Consumer-Driven Contracts" and related articles on evolutionary architecture and architecture decision records.

About the Authors

Hemant Kumar Mahato

Hemant Kumar Mahato is a Principal AI Solution Architect and Regional Head – UAE at Space Inventive, leading enterprise AI strategy and architecture across regulated and high-stakes environments. He works at the intersection of AI, cloud, platform engineering, and organizational design, helping enterprises move from experimentation to resilient, scalable, and governable production systems. His focus is on shaping architectures that evolve with changing business needs while balancing innovation, trust, operational excellence, and long-term adaptability.

Show moreShow less

Łukasz Sieczkowski

Łukasz Sieczkowski is Software Architect at Descartes Systems Group, the company behind the Global Logistics Network (GLN). Curious about machine learning and large language models. Passionate about cycling.

Show moreShow less

Vijayasenthilkumar Kuppusamy

Vijaysenthilkumar Kuppusamy is a Staff Software Engineer focused on cloud platforms, software architecture, distributed systems, and AI. He is passionate about solving complex engineering problems and exploring how systems thinking and ideas from science and technology can shape better software and engineering practices.

Show moreShow less