Our Helsinki multi-agent orchestration projects follow a methodology designed for enterprise reliability and EU compliance: (1) Use case definition and agent architecture (weeks 1-2): designing the system before building it. Use case validation: not every complex task benefits from multi-agent orchestration. We evaluate: task decomposability (can the task be broken into distinct, parallelisable subtasks? If the task is inherently sequential with each step depending entirely on the previous, multi-agent adds overhead without benefit), specialisation benefit (do different subtasks require different capabilities? If every subtask uses the same model with similar prompts, a single agent with a structured prompt may be simpler and equally effective), reliability requirement (does the task require higher reliability than a single LLM can provide? Multi-agent systems can implement cross-validation, where one agent checks another's output — providing error detection that single-agent systems cannot), and scale requirement (does the task involve processing volumes that a single agent cannot handle within time constraints? Multi-agent parallelisation enables processing that would be sequentially too slow). Agent architecture design: defining the agents, their responsibilities, and their interactions. For each agent: role (what does this agent do?), capability (which model or tool does it use?), inputs (what data does it receive?), outputs (what does it produce?), failure modes (what can go wrong, and how is it handled?), and orchestration (how does it coordinate with other agents?). Architecture patterns: sequential pipeline (agents processing in order — each agent receiving the previous agent's output. Simple, predictable, but no parallelisation), parallel fan-out/fan-in (multiple agents processing simultaneously, with a synthesiser agent combining outputs. Fast, but requiring careful output reconciliation), hierarchical (a manager agent delegating to worker agents, reviewing their outputs, and requesting revisions. More autonomous, but requiring robust manager logic), and consensus-based (multiple agents independently analysing the same data, with disagreements flagged for human review. High reliability for critical decisions, but computationally expensive). (2) Agent development (weeks 2-5): building individual agents and the orchestration layer. Model selection per agent: different agents may use different models — GPT-4 for complex reasoning (strategy, synthesis, creative analysis), Claude for long-context processing (document analysis, code review), GPT-3.5-turbo for simple, high-volume tasks (classification, routing, extraction), specialised models for domain-specific tasks (financial calculations, medical NLP), and code execution agents (Python runtime for data analysis, SQL execution for database queries, API calls for external data). Prompt engineering: each agent's prompts engineered for reliability. Structured output (JSON schema-defined outputs — ensuring agent outputs are machine-parseable and validatable), few-shot examples (domain-specific examples embedded in prompts — improving accuracy for specialised tasks), chain-of-thought (for reasoning agents — requiring the agent to show its reasoning, enabling quality validation), and safety guardrails (instructions preventing agents from exceeding their defined scope, generating harmful content, or providing advice in domains where they're not qualified). Orchestration layer: the coordination system managing agent execution. Technology: LangGraph (for complex agent workflows with state management), CrewAI (for role-based agent collaboration), or custom orchestration (Python-based — when the specific workflow requirements don't fit pre-built frameworks). The orchestration layer: managing agent execution order, passing data between agents, handling retries and errors, enforcing timeout limits (preventing agents from running indefinitely), logging all agent inputs and outputs (for audit and debugging), and implementing human-in-the-loop checkpoints (where the workflow pauses for human review before proceeding). (3) Tool and data integration (weeks 3-5): connecting agents to Finnish enterprise systems. Data agents: connecting to the organisation's databases, APIs, and file systems. Finnish-specific integrations: SAP (dominant in Finnish enterprise), Microsoft Dynamics (common in Finnish mid-market), Finnish banking APIs (PSD2 open banking — Finnish banks providing account information and payment initiation APIs), Kanta (Finland's national health data repository — for healthcare applications, with strict access controls and consent requirements), and Suomi.fi (Finland's e-government service platform — for public sector integrations). Tool agents: agents that execute actions rather than just analyse data. File processing (reading and writing documents — supporting Finnish character encoding), calculation (performing financial, statistical, or engineering calculations), web search (retrieving current information — news, market data, regulatory updates), and code execution (running analysis scripts, generating visualisations, and processing data). Security: each agent having minimal permissions — a data-reading agent cannot write data, an analysis agent cannot access systems beyond its scope. The principle of least privilege applied to AI agents, not just human users. (4) Testing and validation (weeks 5-7): ensuring the system works reliably. Unit testing: each agent tested independently — verified inputs, expected outputs, and edge cases. Finnish-specific: testing with Finnish language data, Finnish date formats (dd.mm.yyyy), Finnish number formats (1 234,56), and Finnish-specific domain terminology. Integration testing: agents tested in combination — verifying that outputs from one agent are correctly consumed by the next, that error handling works across agent boundaries, and that the orchestration layer manages failures gracefully. Adversarial testing: deliberately providing incorrect, ambiguous, or contradictory inputs — verifying that the system handles these cases safely (flagging for human review rather than producing confident but wrong outputs). Performance testing: measuring end-to-end execution time, cost per execution (aggregate API costs across all agents), and throughput under concurrent execution. Finnish enterprise expectations: systems must be reliable and performant — "it mostly works" is not acceptable. Compliance validation: EU AI Act requirements verified — risk classification documented, transparency requirements met (users informed about AI processing), human oversight capability demonstrated, and audit trail completeness verified. (5) Deployment and monitoring (weeks 6-8): operational deployment. Deployment: containerised deployment on EU-hosted infrastructure (AWS eu-north-1 Stockholm or Azure North Europe — providing EU data residency for Finnish compliance requirements). Monitoring: comprehensive observability — agent execution metrics (success rate, latency, cost per agent, error frequency), output quality metrics (accuracy measurements where ground truth is available, user satisfaction ratings), drift detection (monitoring for degradation in agent performance over time — particularly important as underlying models are updated by their providers), and cost monitoring (multi-agent systems can generate significant API costs — monitoring and alerting on cost per execution, total daily cost, and cost anomalies). Feedback loop: user feedback on agent outputs feeding back into prompt refinement and agent configuration — continuous improvement based on production usage.