Controlled agentic architecture
How do you choose the components, autonomy limits and tests for an AI agent before implementing it?
1960 € per session, excl. VAT
In short
This 7-hour day, excluding breaks, enables participants to design an agentic architecture suited to a specific business process. Participants weigh up deterministic automation against an agent, specify interactions with data and tools, then test their design against documented scenarios to prepare for a controlled implementation.
Why this training?
An agent that consults documents and calls tools introduces risks distinct from those of a conversational assistant: unauthorised action, execution loops, propagation of incorrect information or data exposure. Formalising each component’s responsibilities makes it possible to discuss trade-offs between autonomy, reliability, latency and execution cost. A testable dossier avoids confusing a convincing demonstration with a usable architecture. Running case study: The fictitious organisation « Brumelis Maintenance » wants to assist with processing service requests: consulting technical documentation, checking a piece of equipment and preparing a ticket. The agent must neither modify equipment nor initiate a service intervention without human approval. The exercises use only fictitious or anonymised data. Transfer to the workplace: Have the dossier reviewed by those responsible for business operations, security and IT operations, then arrange an isolated prototype using the selected scenarios before making any decision to deploy to production.
Objectives of this training
- Define the boundaries of tasks delegated to the agent and decisions reserved for humans
- Compare deterministic orchestration with an agentic loop
- Diagram components, data flows and trust boundaries
- Specify tool contracts and error-handling rules
- Evaluate the design using normal and adverse scenarios
Who is it for and what are the prerequisites?
Roles and tasks concerned
- Software architects and technical leads integrating agentic capabilities
- AI product managers and business analysts responsible for a tool-supported process
- Software or data engineers contributing to interfaces and evaluation
Prior skills
- Have practical experience of generative AI and understand its reliability limitations.
- Understand APIs, permissions and structured data exchanges.
- Be able to describe a business process and its exceptions.
What you will work on
Define delegation boundaries
Objective: Justify the use of an agent. Deterministic tasks, uncertainty, autonomy and the consequences of errors.
Choose the orchestration
Objective: Describe bounded execution control. Single agent, explicit orchestration, state, stopping conditions and call budget.
Organise context and knowledge
Objective: Separate knowledge, instructions and state. Document retrieval, provenance, freshness, temporary memory and retention.
Define tool contracts
Objective: Make interactions verifiable. Input and output schemas, validation, timeouts, retries and duplicate prevention.
Put safeguards in place
Objective: Limit actions and exposure. Least privilege, human approval, untrusted external content and sanitised logging.
Test the architecture
Objective: Measure the quality of the planned decisions. Expected outcomes, task success, traceability, unnecessary calls and simulation limitations.
Prepare the implementation
Objective: Turn deviations into technical decisions. Trade-offs, instrumentation, acceptance thresholds, responsibilities and rollback.
What you take away
- Architecture dossier with a flow diagram and a trade-off log
- Tool contracts and permissions matrix
- Scenario set and completed evaluation grid
- Phased implementation plan with progression criteria
Method and assessment
- Short instructional sessions followed by immediate practice on the running case study.
- Individual work followed by work in pairs, with peer review of the outputs.
- Guided group review: what works, what needs to be corrected and what remains a human decision.
- Preparation: Select a candidate process and describe its sensitive decisions without sharing confidential data. Check which tools the organisation authorises; plan a document-based simulation if no technical environment is accessible.
Observable criteria: Each sensitive action has explicit authorisation and a human approval point. ; Each flow specifies its source, destination and the data exchanged. ; Each tool documents inputs, outputs, permissions and error handling. ; The scenarios cover success, missing information, instruction injection and tool unavailability. ; The measurements distinguish simulated results from performance that still needs to be verified on a prototype..
Frequently asked questions
Is programming required during the day?
No. The contracts and tests can be produced as documents; no working deployment is required.
Is a multi-agent architecture necessary?
No. It must reflect a justified separation of responsibilities without unnecessarily multiplying interactions.
Can an internal case be used?
Yes, after anonymisation and only with tools authorised by the organisation.
Does simulation prove reliability in production?
No. It checks design consistency; latency, cost and robustness then require measurements on a prototype.
Last updated: