Executive summary

Project Controls has data in abundance, but insight remains scarce.

The discipline has long relied on powerful but fundamentally passive and siloed tools. Oracle Primavera P6 models schedules with precision. Dedicated risk software quantifies uncertainty. Email clients manage correspondence. Yet these systems operate in isolation, leaving practitioners to manually bridge the gaps—a process that consumes a disproportionate share of working hours.

This paper presents an alternative architecture: one that shifts from passive reporting to active agentic assistance. Rather than another dashboard or integration layer, the approach involves a coordinated set of AI agents—an orchestrator, a Project Controls manager agent, a risk agent, and a communication agent—each specialized for a distinct domain but capable of working in concert.

The following sections first examine the operational context—the problem this architecture addresses and the measurable outcomes it enables—followed by a mid-to-high level technical explanation of how the multi-agent system functions.

Overview · The problem

The cost of disconnection: where does the time go?

Industry research reveals a consistent pattern. The SmartPM "State of Construction Scheduling 2025" report found that 44% of Project Controls professionals spend more than 10 hours per week on reporting. Only 58% consider this time well spent. Meanwhile, 88% of schedules analyzed fail to meet best-practice standards for data integrity.

The underlying issue is not a shortage of tools, but a fragmentation of information. Field realities surface in email threads before they reach the schedule. This creates several compounding problems:

The context-switching overhead

Practitioners move continuously between Outlook, Primavera, Excel, and risk registers. Each system holds part of the picture; none provides the full view. The human professional functions as the integration layer, copying, pasting, and reconciling data across platforms. This is a structural inefficiency.

Delayed risk identification

Signals often appear in project correspondence—an RFI mentioning procurement issues, an email thread about a labor constraint—days or weeks before they are formally logged. By the time risks surface in monthly reviews, the window for proactive mitigation has narrowed or closed. The industry operates in a largely reactive mode.

Misallocated expertise

Professionals trained in CPM scheduling and quantitative risk analysis spend a significant portion of their time on data entry, report formatting, and narrative generation. This is not an efficient use of specialized skills. The latent cost of data capture, transformation, and reconciliation is substantial.

Overview · The solution

A multi-agent architecture, not a chatbot

The system described here differs structurally from a conventional chatbot or single-purpose AI assistant. It is an orchestrated set of specialized agents, each with its own domain expertise, toolset, and data access. Together, they consolidate schedule, risk, and communication data into a unified, responsive layer.

The orchestrator

At the center of the architecture is an orchestrator. When a user submits a request—for example, "Check the schedule variance on the electrical package and draft an email to the subcontractor"—the orchestrator parses the intent and coordinates the relevant sub-agents. A multi-domain request is decomposed into discrete tasks, delegated to specialists, and then synthesized into a coherent response. The user interacts with one interface; multiple agents collaborate in the background.

Context-aware access

Unlike general-purpose LLMs that operate without project context, this system has controlled access to critical data sources:

• Historical context: The communication agent can query the project's email database, retrieving past commitments, disputes, and agreements.
• Schedule logic: The PC manager agent understands WBS hierarchies, critical path calculations, and float consumption, and can query the P6 database directly.
• External data: The risk agent can perform real-time web searches to validate internal concerns against market conditions (e.g., expected material price movements).

Overview · Capabilities

Agent specialization by domain

The Project Controls manager agent

This agent serves as the interface for schedule and cost data. Its capabilities include:

• Schedule queries: A user can ask, "What activities are starting next week on the mechanical scope?" and receive a structured response drawn directly from the P6 database.
• Field-to-schedule bridging: The largest latency in schedule management is often the gap between field conditions and the baseline. This agent enables field personnel to log progress in natural language—"We completed concrete pouring on Foundation B today"—which is then structured and queued for scheduler review. Reporting latency decreases without bypassing the scheduler's approval authority.

The risk agent

This agent is designed for early risk identification and validation:

• Correspondence scanning: The agent can be configured to monitor incoming emails for language indicating emerging risks—mentions of delays, cost escalations, or resource constraints—and surface them for human review.
• External validation: When an internal concern is raised (e.g., supply chain uncertainty for a specific material), the risk agent can query external sources for current market news and supply chain data.

The communication agent

This agent addresses the administrative load of project correspondence:

• Context-aware drafting: When drafting a response, the agent queries the communication database to understand the thread's context, references specific WBS elements or prior agreements, and produces a draft that maintains project-specific accuracy.
• Reduced drafting time: Preparing correspondence for review is time-intensive. The communication agent produces initial drafts, allowing the professional to edit and approve rather than compose from scratch.

Overview · Outcomes

Measurable outcomes: time reallocation

The primary outcome of an agentic Project Controls architecture is the reallocation of professional time from routine data tasks to analysis and decision-making. The following metrics characterize this shift:

1. Administrative time recovered

If a Project Controls professional currently spends 10+ hours per week on reporting and data reconciliation, a 60% automation rate returns approximately 6 hours weekly. Across a team of five, that is 30 person-hours per week—nearly equivalent to an additional resource focused on analysis rather than data processing. Industry estimates for AI-augmented project management suggest productivity gains in the 20-30% range.

2. Response latency

The elapsed time from "risk signal identified in correspondence" to "mitigation plan drafted and assigned" is a key metric. In conventional workflows, this can span days or weeks as information moves through review cycles. An agentic system can detect the signal, draft a risk entry, and route it for approval within minutes. Organizations testing similar architectures report response latency reductions of 60% or more for common scenarios.

3. Schedule fidelity

Schedule drift—the divergence between baseline and field reality—is often driven by reporting latency. When field progress is captured via natural language and processed in near real-time, the schedule more accurately reflects current conditions. Higher schedule accuracy enables earlier identification of emerging delays and more effective recovery planning.

Boundaries of automation

It is worth noting what remains outside automation scope. Strategic decisions, stakeholder negotiations, final approvals, and the exercise of professional judgment stay with humans. The agentic system handles preparatory work—gathering data, drafting reports, flagging anomalies—so that professionals can focus on consequential decisions.

Technical · Workflows

Workflow orchestration: from request to execution

The system is structured around defined workflows rather than ad-hoc LLM prompting. Each user request triggers a workflow—a sequence of agent invocations, tool calls, and state transitions—managed by a central orchestrator. This design ensures repeatability, auditability, and the ability to enforce governance at each step.

Workflow definition

Workflows are defined as directed graphs where nodes represent agent actions and edges represent transitions conditioned on outputs. A typical workflow for a risk-related query might proceed as follows:

1. Intent classification: The orchestrator determines the request category (schedule, risk, communication, or hybrid).
2. Agent delegation: The request is routed to the appropriate specialized agent—or multiple agents in sequence for cross-domain queries.
3. Tool execution: Each agent calls its bound tools (database queries, email searches, web lookups) and collects results.
4. State aggregation: Outputs are merged into a shared ConversationState object that persists across the workflow.
5. Response synthesis: The orchestrator compiles agent outputs into a unified response for the user.

Human-in-the-loop checkpoints

Certain workflows include explicit human checkpoints. For example, when the risk agent proposes a new risk register entry, the workflow pauses and routes the draft for human approval before committing it to the database. This ensures that AI-generated content is reviewed before it becomes an official project record.

Built-in governance

Workflow definitions encode governance rules: which actions require approval, which users can trigger specific workflows, and what audit data is captured at each step. These rules are not afterthoughts—they are structural elements of the workflow graph.

Technical · Orchestration

The orchestrator graph: state machines for AI coordination

The orchestrator is implemented as a finite state machine (FSM) using pydantic-graph. This is not a simple chain of prompts—it is a structured execution model that manages agent lifecycles, handles branching logic, and maintains state consistency across multi-step operations.

Graph nodes and edges

Each node in the graph represents an atomic operation: an agent invocation, a tool call, a decision point, or a state checkpoint. Edges define transitions, which can be conditional (execute node B only if node A returns a specific status) or parallel (execute nodes B and C concurrently).

For a cross-domain query such as "Check the critical path status and draft a delay notification email," the graph might instantiate:

• A schedule node that invokes the PC manager agent to query P6 and identify critical path activities.
• A communication node that invokes the communication agent to draft the notification, using the schedule data as context.
• A merge node that combines outputs into a final response.

Ephemeral state management

The graph maintains a ConversationState object throughout execution. This object carries context between nodes: emails retrieved by one agent become available to subsequent agents; risk flags raised early in the workflow inform later drafting decisions. State is ephemeral by design—it exists for the duration of the request and is not persisted beyond the response, unless explicitly committed to the database via an approved action.

Error handling and recovery

The graph model supports explicit error handling. If a tool call fails (e.g., an external API timeout), the graph can retry, fall back to an alternative path, or escalate to human intervention—depending on the workflow definition. This is a fundamental difference from fragile prompt chains that fail silently or unpredictably.

Technical · Security & tracing

Data isolation and full-stack observability

Deploying AI agents in project environments introduces security and auditability requirements that are not optional. The architecture enforces data isolation at multiple layers and captures a complete trace of every agent decision.

Row-level security (RLS)

Every database query—whether initiated by a human user or an AI agent—passes through Supabase RLS policies. These policies filter results by the invoking user's explicit project and organization assignments. An agent acting on behalf of a user cannot access data that user is not authorized to see. Multi-tenancy is enforced at the database level, not merely at the application layer.

Agent-scoped permissions

Each agent operates with a defined set of tool bindings. The risk agent cannot invoke email-sending tools; the communication agent cannot modify schedule data. This principle of least privilege limits the blast radius of any single agent malfunction or prompt injection attempt.

Full-stack tracing with Logfire

The system is instrumented with Pydantic Logfire. Every span of execution—from the initial request, through intent classification, to each tool invocation and final response—is captured with structured metadata. This tracing supports:

• Debugging: When an agent produces an unexpected output, engineers can replay the execution trace step-by-step, inspecting tool inputs, LLM reasoning, and state transitions.
• Audit trails: For compliance and dispute resolution, the system provides a complete record of what the agent did, what data it accessed, and what outputs it generated—timestamped and linked to the invoking user.
• Performance monitoring: Latency metrics for each tool, agent, and workflow enable capacity planning and identification of bottlenecks.

Conclusion

A path forward: AI as a working resource

The opportunity for Project Controls is substantial. The same technology that has reshaped customer service, legal research, and software development can be applied to schedule and risk management—provided the architecture is appropriate.

A single chatbot, without project context or domain logic, produces generic and often unreliable outputs. A multi-agent system, grounded in structured ontologies (WBS, cost codes, risk taxonomies) and integrated with authoritative data sources (P6, email, risk registers), can address the 60-80% of data labor that currently absorbs professional hours.

Adoption considerations

A pragmatic adoption path might include:

1. Quantify data labor. Before investing in automation, measure where time is currently spent. Most organizations find the results instructive.
2. Evaluate ontology depth. AI claims are common. Ask: what domain knowledge does the system encode? Does it understand WBS, critical path, and risk taxonomies?
3. Require accountability workflows. AI should draft; humans should approve. Clear audit trails and human sign-off at decision points are non-negotiable.
4. Start with low-risk, high-volume tasks. Report generation, email summarization, and progress logging are suitable initial targets. Build confidence before extending to higher-stakes workflows.