{"id":2981,"date":"2026-05-18T13:00:55","date_gmt":"2026-05-18T13:00:55","guid":{"rendered":"https:\/\/www.castelis.com\/?post_type=article&#038;p=2981"},"modified":"2026-05-18T13:01:02","modified_gmt":"2026-05-18T13:01:02","slug":"software-architecture-agentic-systems","status":"publish","type":"article","link":"https:\/\/www.castelis.com\/en\/insights-ressources\/software-architecture-agentic-systems\/","title":{"rendered":"Software Architecture in the Age of Agentic Systems"},"content":{"rendered":"\n<p>Autonomous AI agents no longer just respond. They make decisions, execute actions, and modify your information system without waiting for explicit instructions. This autonomy challenges the very foundations of software architecture as we know it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The Gap: Architectures Built for Predictability<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">How Classic Architectures Work<\/h3>\n\n\n\n<p>Traditional software architectures (monoliths, microservices, event-driven) rest on a principle: each component executes explicit instructions according to predefined rules. An order management microservice receives a request, applies deterministic logic, and returns a response. Everything is traced, predictable, auditable.<\/p>\n\n\n\n<p>This predictability allows architects to draw clear diagrams. If the user does A, the system does B. If stock is empty, the order is blocked. Patterns like CQRS or Saga rely on this certainty: we know in advance what each component can do.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What AI Agents Change<\/h3>\n\n\n\n<p>An AI agent analyzes context, reasons about the objective to achieve, and autonomously determines which actions to undertake. It doesn&#8217;t execute a pre-established script. It decides. This autonomy creates a gap between architectures designed for rigid processes and agents capable of unpredictable decisions.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The New Architectural Challenges<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Agent Coordination<\/h3>\n\n\n\n<p>Agents can act simultaneously on the same data without centralized coordination. Unlike microservices that collaborate according to predefined orchestrations, agents decide on the fly.<\/p>\n\n\n\n<p><strong>Example:<\/strong> A system deploys three agents: support, billing, loyalty. A customer reports a defective product. The support agent processes the complaint while the billing agent generates a payment reminder and the loyalty agent offers a discount voucher. The customer simultaneously receives a refund, a late payment reminder, and a compensation voucher. Three contradictory actions, no coordination.<\/p>\n\n\n\n<p>Traditional coordination patterns (orchestrator, saga) assume predefined sequences. Here, sequences emerge from context. We need to rethink coordination for unprogrammed workflows.<\/p>\n\n\n\n<p>According to Gartner, by 2028, 33% of enterprise applications will include agentic AI, up from less than 1% in 2024 (<a href=\"https:\/\/www.gartner.com\/en\/articles\/top-technology-trends-2026\" target=\"_blank\" rel=\"noopener\">Source: Gartner, 2025<\/a>). This growth makes coordination critical.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Action Governance<\/h3>\n\n\n\n<p>An agent with database access can theoretically perform any operation authorized by its permissions. However, classic access controls (RBAC, ACL) were designed for human users or deterministic processes, not for entities capable of discovering new actions.<\/p>\n\n\n\n<p><strong>Example:<\/strong> An agent automates supplier contract management with read\/write access. A supplier contacts the agent to renegotiate. The agent decides to unilaterally reduce prices by 30% to &#8220;maintain the business relationship.&#8221; Technically, it had the rights. Strategically, it&#8217;s a disaster.<\/p>\n\n\n\n<p>Access controls answer &#8220;who can do what?&#8221; but not &#8220;in which business context is this action legitimate?&#8221; We need guardrails that go beyond technical permissions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Decision Traceability<\/h3>\n\n\n\n<p>Traditional logs record &#8220;what happened,&#8221; not &#8220;why.&#8221; With agents, the &#8220;why&#8221; is crucial.<\/p>\n\n\n\n<p><strong>Example:<\/strong> An incorrect invoice applies a 50% discount instead of 10%. Tracing back the chain, we discover that a loyalty agent had marked the customer as &#8220;priority VIP&#8221; following a complaint. The billing agent interpreted this status as a signal to apply maximum discount. Neither violated their rules.<\/p>\n\n\n\n<p>Traceability for agentic systems requires a decision graph model. Each decision must be recorded with its context: data consulted, inferences drawn, alternatives considered, reason for the choice.<\/p>\n\n\n\n<p>This traceability has a cost in storage and performance, but becomes essential for debugging and regulatory compliance (GDPR, AI Act).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Data Consistency<\/h3>\n\n\n\n<p>Agents read and modify data over workflows spanning several minutes or even hours. ACID transactions, effective for atomic operations, no longer hold.<\/p>\n\n\n\n<p><strong>Example:<\/strong> An agent reads 10 units in stock and decides to order 5 additional units. During price negotiation (2 minutes), a second agent reserves 8 units. When the first agent finalizes, actual stock is at 2 units, but it orders based on 10. Result: unnecessary overstock.<\/p>\n\n\n\n<p>Event-driven architectures (Event Sourcing, CQRS) offer paths forward, but require adaptations: optimistic locking, contextual validations before commit, compensation procedures in case of late conflict.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">System Observability<\/h3>\n\n\n\n<p>Traditional metrics (latency, throughput, error rate) no longer suffice. They provide a technical view, not a behavioral one.<\/p>\n\n\n\n<p><strong>Example:<\/strong> The dashboard displays &#8220;200 requests\/minute, 120ms latency, 0% error.&#8221; Everything seems nominal. Yet agents consume massive volumes of LLM tokens, generating unexpected costs. Some enter infinite reasoning loops, blocking business workflows. Technically, no error. Functionally, the system is broken.<\/p>\n\n\n\n<p>We need to track: active agents, actions per agent, average decision chains, LLM tokens consumed, human escalation rate, objective resolution time. These metrics detect abnormal behaviors before they degrade service.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">New Architecture Patterns<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Supervisor Agent Orchestration<\/h3>\n\n\n\n<p>A supervisor agent centralizes coordination decisions. It receives intentions from other agents, arbitrates their execution, decides action order, and resolves conflicts. This pattern suits environments where consistency trumps reactivity (finance, critical workflows). The flip side: the supervisor becomes a potential contention point, and agents lose part of their autonomy.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Action Whitelisting<\/h3>\n\n\n\n<p>Each agent has an explicit list of authorized actions. Any action outside the list is blocked by default, even if the agent has technical permissions. This approach inverts the traditional security model and effectively prevents unexpected actions. Recommended for agents interacting with sensitive data (finance, personal data, production systems). The trade-off: increased rigidity and heavy list maintenance.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Automatic Escalation<\/h3>\n\n\n\n<p>Rules automatically trigger human validation for certain actions: financial amount, data criticality, agent confidence level, number of reasoning steps. This guardrail doesn&#8217;t prevent autonomy on simple tasks, but slows workflows requiring validation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Decision Graph Traceability<\/h3>\n\n\n\n<p>Each agent decision is recorded as a graph: data consulted, reasoning performed, actions executed, step order. This graph allows complete path reconstruction and becomes essential in regulated environments (health, finance, public sector) where automated decision traceability is legal. The cost: storage overhead and implementation complexity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Domain Isolation<\/h3>\n\n\n\n<p>Each agent operates within a limited business domain and cannot exit its perimeter. An order management agent that needs to reserve stock solicits a &#8220;Stock&#8221; domain agent via an explicit API, rather than accessing the database directly. This separation limits impacts in case of failure, but restricts possible use cases.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th>Pattern<\/th><th>Main Advantage<\/th><th>Main Drawback<\/th><th>Typical Use Case<\/th><\/tr><\/thead><tbody><tr><td>Supervisor agent<\/td><td>Centralized control<\/td><td>Bottleneck<\/td><td>Finance, critical workflows<\/td><\/tr><tr><td>Action whitelist<\/td><td>Enhanced security<\/td><td>Rigidity, heavy maintenance<\/td><td>Sensitive data<\/td><\/tr><tr><td>Automatic escalation<\/td><td>Guardrail without total blocking<\/td><td>Slows certain workflows<\/td><td>Selective human validation<\/td><\/tr><tr><td>Decision graph<\/td><td>Total auditability<\/td><td>Storage overhead<\/td><td>Regulated environments<\/td><\/tr><tr><td>Domain isolation<\/td><td>Impact limitation<\/td><td>Restricts use cases<\/td><td>DDD architecture<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">What Architects Must Do Now<\/h2>\n\n\n\n<p><strong>Map risks.<\/strong> Identify which agents will access which data and assess the impact of an erroneous action. This mapping allows prioritizing security efforts.<\/p>\n\n\n\n<p><strong>Define autonomy levels.<\/strong> Classify agents into three categories: full autonomy, supervised autonomy, pure assistance. This classification must be documented and regularly revised.<\/p>\n\n\n\n<p><strong>Implement technical guardrails.<\/strong> Action whitelists, escalation rules, structured logs. These guardrails must be tested before production.<\/p>\n\n\n\n<p><strong>Test failure scenarios.<\/strong> Simulate two agents acting simultaneously, an agent making a wrong decision, canceling an action sequence. These tests reveal flaws before production.<\/p>\n\n\n\n<p><strong>Set up observability.<\/strong> Specific dashboards: active agents, actions per agent, decision chains, LLM costs, escalation rate. Alerts on abnormal behaviors.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Agentic systems challenge the foundations of modern software architecture. Proven patterns (microservices, event-driven, CQRS) remain valid, but no longer suffice. They must be complemented with new coordination, governance, and observability mechanisms.<\/p>\n\n\n\n<p>Organizations integrating these patterns now deploy AI agents in production in a controlled, secure, and auditable manner. Others will suffer incidents, cost overruns, and functional inconsistencies.<\/p>\n\n\n\n<p>The question is no longer whether you&#8217;ll deploy AI agents in your IS. The question is: is your architecture ready?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Autonomous AI agents no longer just respond. They make decisions, execute actions, and modify your information system without waiting for explicit instructions. This autonomy challenges the very foundations of software architecture as we know it. The Gap: Architectures Built for Predictability How Classic Architectures Work Traditional software architectures (monoliths, microservices, event-driven) rest on a principle: &hellip; <a href=\"https:\/\/www.castelis.com\/en\/insights-ressources\/software-architecture-agentic-systems\/\">Continued<\/a><\/p>\n","protected":false},"author":2,"featured_media":2980,"template":"","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[],"tags":[],"class_list":["post-2981","article","type-article","status-publish","has-post-thumbnail","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article\/2981","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article"}],"about":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/types\/article"}],"author":[{"embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/users\/2"}],"version-history":[{"count":3,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article\/2981\/revisions"}],"predecessor-version":[{"id":2984,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/article\/2981\/revisions\/2984"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/media\/2980"}],"wp:attachment":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/media?parent=2981"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/categories?post=2981"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/tags?post=2981"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}