AI coding agents deliver working software at a remarkable pace, but they know nothing about your organization: what systems exist, what they’re called, and what rules apply. Enterprise architecture provides exactly this context in written form.
Agents without an architectural context produce software that works on its own but does not fit into the surrounding landscape. Correcting this later is expensive.
01
The metamodel defines the vocabulary
Agents must understand your company's language. The metamodel defines capabilities, applications, processes, and data objects, as well as their relationships. Together with agreed-upon definitions, these concepts form the shared ontology that all agents use.
02
The repository gives it meaning
The repository applies this ontology to your company. It describes what capabilities and data objects represent, which systems they support, who is responsible for them, and how everything is interconnected. This enables agents to work with reliable, well-maintained corporate knowledge rather than making assumptions.
03
Principles are the guardrails
Architectural principles, standards, and process models can be directly translated into specifications and acceptance criteria against which agents are evaluated and which reviewers can verify.
04
Governance is the level of control
Decision-making processes, decision documentation, and the obligation to provide evidence remain just as relevant when a machine writes the code. They form the basis for your ability to take responsibility for the result.
How We Work
Engineering discipline: " " at the pace of agents.
We develop software featuring AI agents in production environments, including our own enterprise platform. This approach has proven successful, and we are implementing it in collaboration with our customers.
01Specification-Driven Development
Specification prior to implementation.
Using prompts and accepting the result is acceptable for prototypes, but not for software that people rely on. For larger features, we take a specification-driven approach: use cases, functional and non-functional requirements, edge cases, and acceptance criteria are documented before implementation begins. The developers build against this specification and derive the tests from the requirements rather than from the generated code, ensuring that the tests describe the intended behavior.
How You Benefit: Consistent performance, because the specification remains the reference even if the feature is expanded later.
Use Cases & Requirements
Acceptance Criteria
Tests Based on Requirements
Spec-driven tooling
Definition of "Ready"Gate
Before an agent gets started.
Use cases written and reviewed
Explicit Non-Functional Requirements
List of Edge Cases
Tests Based on Requirements, Not on Code
"The prompt sounds just right."
Requirement
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 shut down last year, or an integration pattern that you have since abandoned. We provide the architecture repository as a working context so that agents can build against the applications, interfaces, and data objects that actually exist. The metamodel serves both purposes simultaneously: as a model maintained by your architects and as a common vocabulary that your agents follow.
How You Benefit: Results that fit into the existing landscape, and less time spent reviewing and correcting unfounded assumptions.
Repository as Context
Shared Vocabulary
Landscape-Conscious Results
Fewer hallucinations
03Guardrails
Defined boundaries for agents.
Architectural decisions must be binding, and when it comes to agents, they must be enforceable throughout the entire delivery pipeline. We translate stack decisions, integration patterns, security requirements, and process models into explicit guidelines: which patterns are mandatory, which components must not be modified, and which changes first require a human decision. Without these boundaries, each session introduces its own patterns, and the codebase gradually loses its structure.
What You Get: A codebase that maintains a consistent architecture even after hundreds of contributions from agents.
Binding Stack Decisions
Mandatory Templates
Criteria from Processes
Human Decision Points
Employment AgreementAgents
What agents are allowed to change.
Only approved patterns and stacks
Architectural decisions are binding
Schema and API changes require human approval
New dependencies require human approval
The authorization and audit code will not be changed
Enforced
04Review & References
Automated review, documented evidence.
Generated code must be reviewed. Given the volume of code that agents produce, this review must be automated. We set up automated code reviews that run with every commit and flag typical risks in generated code: specific logic errors as well as vulnerabilities related to permissions and other cross-cutting concerns. At the same time, we provide the necessary documentation, as compliance requirements apply regardless of who wrote the code. As a TISAX-certified company, we must demonstrate that we follow a controlled development process ourselves and apply the same standards to customer projects.
How You Benefit: Errorsare detected before the merge, and the review and test history is available for audits.
Automatic Review for Each Commit
Authorization Checks
Traceable History
Audit-proof evidence
Review JournalThis Week
Every change has been documented.
Change 481Tests ✓ · Review ✓ · Merged
Amendment 482Back: Authorization Gap
Amendment 482 Rev. 2Tests ✓ · Review ✓ · Merged
Change 483Tests ✓ · Review ✓ · Merged
The complete history of decisions and tests remains available.
Audit Festival
05Where It Fits
The right area of application for agent-based development.
Agent-based 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 becomes a shared digital backbone and every feature must take into account permissions, notifications, audit logging, and existing modules. We’ll help you realistically assess your project—even if licensing a product is the better solution.
What You Get: An informed make-or-buy decision before the budget is finalized.
Internal Applications
Extensions & Reports
Integrations & Tooling
Make-or-Buy Consulting
EvaluationMake or Buy
Internal asset management tool.
Limited scope
We have the requirements
Cross-Sectional Responsibilities
Standard product available
RecommendationBuilding, agent-based
Tested on our own platform
Our platform, , is written by agents.
ITM InMind is our internal corporate 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 day-to-day operations, so we know from experience where this approach works and where its limitations lie.
Most teams use agents to build a working prototype within a few days and then run into the same obstacles. In our experience, the cause is rarely the model itself, and it can rarely be resolved by further refining the prompts.
