learntodriveai.dev/Data Science/AI Infrastructure at Scale: Multi-Agent Analytical Work
Data Science·Project 13·7 units

AI Infrastructure at Scale: Multi-Agent Analytical Work.

**Track:** Data Science

§ Brief

You are continuing the Gulf Sky Airlines flight delay engagement Fatima opened with you last project. The five specifications you delivered are in production-adjacent use, but she has hit a wall trying to scale them: thirty combinations across specifications, preprocessing variants, and thresholds, and no way to trace which result corresponds to which assumptions. A new analyst joins her team next month and needs to load the project and continue without Fatima sitting next to her.

The discipline is the same as last project -- multi-specification flight delay prediction, the same dataset, the same MLflow experiment, the same composition invariants. What changes is how the work gets done: three new specifications run by independent agents in different orchestration modes, each with scoped context and scoped tool access, with you reserving the global coherence judgment that no single agent can make.

The AI-direction lesson: when AI infrastructure is load-bearing, the professional contribution shifts from "produce the analysis" to "design the infrastructure and verify the composition holds across agents." Connectivity, context boundaries, project memory, skills, hooks, and orchestration mode are quality decisions with visible analytical consequences. Bad infrastructure does not announce itself; it produces locally correct work that does not compose.

Your Role

You are the architect of the engagement's AI infrastructure and the keeper of cross-agent coherence. You design which tool connects at which phase, what each agent type receives as context, what stays in project memory versus session-only, and which of the three new specifications goes to which orchestration pattern. You verify that the eight specifications compose -- that agents agreed on the load-bearing constraints, not just that each agent's local output looks right. And you produce a handoff package the incoming analyst can use, in whichever AI tool she works in.

What's New

Last project, you advanced the discipline -- multi-specification thinking, MLflow tracking, preprocessing leakage, composition verification across the five specifications. The methodology is settled now. You used the project memory file, the assumption-checking skill, and the pre-evaluation hook that were already in place; you did not architect them.

This project, the architecture decisions come back to you. Same client, same data, same MLflow experiment -- the infrastructure carrying it all is now the variable. You will run the same kind of work in three different orchestration modes (synchronous agent team, orchestrator with hand-offs, async via PR), so the trade-offs are felt rather than described. Phase-scoped connectivity, per-agent context scoping, AI tools serving as MCP servers, auto-memory curation, and portability testing across tools are all new.

The hard part is global coherence at the agent boundary. Each agent will validate its own work and report success. The composition gap between agents -- one applying a different exclusion rule, one assuming a different threshold, one quietly inheriting a contradictory memory entry -- is invisible to every agent and visible only to you.

Tools

  • Python 3.11+ in the conda "ds" environment (carry-forward)
  • Jupyter Notebook (carry-forward)
  • pandas, scikit-learn with Pipeline and ColumnTransformer (carry-forward)
  • MLflow -- the existing gulf-sky-delay-prediction experiment from P12 (carry-forward)
  • DuckDB and DuckDB MCP server (carry-forward, now used phase-scoped)
  • Jupyter MCP server (carry-forward, now used phase-scoped)
  • MLflow MCP server (new) -- experiment-tracking MCP, connected only during the sensitivity-comparison phase
  • Claude Code with the P11+P12 assumption-checking skill and the P11 pre-evaluation hook active (carry-forward)
  • Claude Code as an MCP server (new) -- exposes specific analysis files only, so another tool can request a methodology review through the same protocol you already use for database queries
  • Codex CLI as orchestrator (new use) -- runs an orchestrator pattern with hand-offs between specialized preparation, fit, and review agents
  • GitHub Copilot coding agent (new) -- one specification delegated async via a GitHub issue, returning a PR for review
  • Cursor Background Agents -- referenced for comparison only
  • AGENTS.md (new) -- cross-tool equivalent of the project memory file, written for the portability test
  • Git / GitHub with active use of issues and PRs for async delegation

Materials

The full last-project state (data, MLflow runs, composition-verification notebook, deliverable, methodology note, project memory file, skill, hook) is the starting point -- read in place, not duplicated. This project adds a small overlay of new reference files:

  • A project memory file framing this engagement as the AI-infrastructure continuation and pointing at the existing artifacts
  • A handoff-package template -- seven section headings with prompt-style guidance, no pre-filled body; you write into it across the project
  • An orchestration-modes reference summarising the four multi-agent approaches at the level you need to choose between them, plus the MLflow MCP server install command
  • A specifications backlog from Fatima -- three candidate variations in client language, deliberately under-specified, that you translate into well-formed sensitivity specifications

No connectivity plan, no agent assignment, no portability target. Those are yours to design.