AI coding agents produce working software at a remarkable speed, but they know nothing about your organization—which systems exist, how they are named, and which rules apply. Enterprise Architecture provides exactly this context in written form.
Agents without architectural context produce software that works on its own but does not fit into the surrounding environment. Correcting that later is costly.
01
The meta-model defines the vocabulary
Agents must speak the language of your organization. The meta-model defines capabilities, applications, processes, and data objects, as well as the relationships between them. Together with agreed-upon definitions, these concepts form the shared ontology that every agent uses.
02
The repository establishes the meaning
The repository links this ontology to your enterprise: what each capability and data object means, which systems support it, who owns it, and how everything is related. Agents rely on governed organizational knowledge rather than guesswork.
03
Principles are the guardrails
Architectural principles, standards, and process models translate directly into constraints and acceptance criteria that can be used to evaluate agents and that reviewers can verify.
04
Governance is the control plane
Review paths, decision records, and evidence requirements remain just as relevant when a machine writes the code. They are what allow you to take responsibility for the result.
How We Work
Engineering discipline— , at the speed of an agent.
We develop software that uses AI agents in production environments, including our own business platform. This is the approach we have adopted, and the one we implement with our customers.
01Specification-Driven Delivery
Specification prior to implementation.
Prompting and accepting the result is acceptable for prototypes, but not for software that people rely on. For major features, we follow a specification-first approach: use cases, functional and non-functional requirements, edge cases, and acceptance criteria are documented before implementation begins. The agents build against this specification and derive the tests from the requirements rather than from the generated code, so the tests describe the intended behavior.
What You Get: Sustainablespeed, because the specification remains the standard even when the feature is expanded later.
Use Cases & Requirements
Acceptance Criteria
Tests Based on Requirements
Specification-driven tooling
Definition of "ready"Gate
Before any agent begins.
Use cases written and agreed upon
Explicit non-functional requirements
Edge cases listed
Tests derived from requirements, not code
“The prompt sounds about right”
Required
02Architecture as Context
Rooted in your actual landscape.
An agent that is unfamiliar with your landscape will invent a plausible one—for example, a service that was decommissioned last year or an integration pattern you have since abandoned. We provide the architecture repository as a working context, so agents build based on the applications, interfaces, and data objects that actually exist. The metamodel serves both purposes at once: as the model your architects maintain and as the shared vocabulary your agents follow.
What You Get: Resultsthat align with the existing landscape, and less time spent reviewing and correcting unfounded assumptions.
Repository as context
Shared vocabulary
Landscape-aware output
Fewer hallucinations
03Guardrails
Defined boundaries for agents.
Architectural decisions must be binding, and when it comes to agents, they must be enforceable throughout the delivery pipeline. We translate stack decisions, integration patterns, security requirements, and process models into explicit constraints: which patterns are mandatory, which components must not be modified, and which changes require human approval first. Without these boundaries, every session introduces its own patterns, and the codebase gradually loses its structure.
What you get: Acodebase that maintains a consistent architecture, even after hundreds of agent contributions.
Binding stack decisions
Mandatory patterns
Process-derived criteria
Human decision points
Working AgreementAgents
What agents may change.
Approved patterns and stack only
Architectural decisions are binding
Schema and API changes require human approval
New dependencies require human approval
Access control and audit code remain unchanged
Enforced
04Review & Evidence
Automated review, documented evidence.
Generated code must be reviewed. Given the volume of code produced by agents, that review must be automated. We have set up automated code reviews that run with every commit and flag common risks in generated code: specific logic errors, as well as weaknesses in access control and other cross-cutting concerns. At the same time, we maintain the necessary documentation, because compliance requirements apply regardless of who wrote the code. As a TISAX-certified company, we must demonstrate a controlled development process ourselves and apply the same standard to customer projects.
What You Get: Defectsare caught before the merge, and the review and test history is available for audits.
Automated review per commit
Access control checks
Traceable change history
Audit-ready evidence
Review LedgerThis week
Every change has been accounted for.
Change 481Tests ✓ · review ✓ · merged
Change 482Returned: access control gap
Change 482 rev. 2Tests ✓ · review ✓ · merged
Change 483Tests ✓ · review ✓ · merged
The complete decision and test history remains available.
Audit-ready
05Where it fits
The right scope for agentic development.
Agentic development is particularly well-suited when the scope is manageable and you can clearly define the requirements: internal applications, platform extensions, custom reports, integrations, and migration tools. It becomes more challenging when an application evolves into a shared digital backbone and every feature must account for permissions, notifications, audit logging, and existing modules. We help you realistically assess your initiative, including determining when licensing a product is the better solution.
What you get: Awell-informed build-or-buy decision before the budget is allocated.
Internal applications
Extensions & Reports
Integration & Tooling
Build-or-Buy Advice
AssessmentBuild or Buy
Internal asset management tool.
Scope-bounded
It is up to us to define the requirements
Cross-cutting obligations
Standard product available
RecommendationBuild, agent-based
Tested on our own platform
Our own platform, , is written by agents.
ITM InMind is our internal business platform. Every line of code was written by AI agents, while our developers set the direction, review the results, and test each module. It supports our daily operations, so we know from experience where this approach works and where its limitations lie.
Most teams produce a working prototype with agents within days and then run into very similar obstacles. In our experience, the problem is rarely the model itself, and it is rarely solved by more elaborate prompts.
