Asana as a governed data source: bringing Work Graph context into a secure multi-agent system

The data that makes AI evaluations great lives in data warehouses, production databases, and private systems. Only by accessing these governed systems can you get valuable business context, such as project histories, resourcing, financials, risk signals, etc. That data is valuable precisely because access to it is controlled. You don't want an agent holding a standing key to all of it, and you don't want it acting on work without a trail.

Asana AI Teammates already work across a broad set of connected tools, securely and under enterprise controls, operating inside the Work Graph with the same permissions, visibility, and accountability model as a human collaborator. But in many enterprises, the most valuable data deliberately can't leave its boundary: it sits behind strict data-residency policies, inside a VPC, in systems that simply won't expose a connector for any external service to read. That's not a gap in what Asana can do — it's the enterprise doing its job. And it's exactly the scenario where Asana's value shows up from a second direction.

Through the same API, webhooks, and MCP server any developer can use, Asana becomes part of a larger, more technical agent system that can query at runtime — bringing live operational context into a pipeline that is designed to keep the locked-down data locked down.

This post walks through a reference architecture that does exactly that.

What we built: a three-layer go/no-go evaluator

The use case is project intake. Someone submits a project request in Asana; instead of a human vetting it on gut feel, the request comes back enriched with a risk score, a resource-availability check, historical pattern analysis, and live workspace context — with no manual steps in between. The architecture has three layers:

• Asana as the human interface (left). A form submission creates a task. That task fires a webhook.

• Google Cloud as the reasoning layer (middle). A webhook receiver, an orchestrator, and a set of specialist agents run as Cloud Run services that talk to the model and to a data warehouse.

• Asana as a data source (right). One agent queries the live Work Graph through the Asana MCP server and API — checking for aligning goals, overlapping active projects and current team load.

Webhooks: the workflow trigger

The whole thing starts with a webhook. When a request lands in the intake project as a new task, Asana fires an event to a receiver running on Cloud Run, and that receiver kicks off the evaluation. If you've wired up an Asana webhook before, none of this is new; if you haven't, this webhooks guide covers the handshake and event filtering.

Orchestrating the reasoning layer with Google ADK

It's important to review the tech stack before moving forward. The middle layer is a Google ADK orchestrator that dispatches a set of specialist agents — three in parallel, then one sequentially over the Agent-to-Agent (A2A) protocol. Each agent is its own Cloud Run service that scales to zero between requests, so the whole system is pay-per-request rather than always-on. One agent reasons over historical patterns in BigQuery; another queries the live Work Graph through the Asana MCP server. The orchestrator doesn't know how any of them work internally — it sends a task to a URL and waits for a result, which means you can swap an agent or add a new one without touching the orchestration logic.

None of these pieces are bespoke to this demo; they're standard, composable building blocks, and Asana plugs into them through the same open standards as everything else.

And because key agent actions, metadata, and inter-agent handoffs are logged through Google Cloud Logging, the pipeline offers auditability and operational visibility that supports execution against enterprise data.

Querying the Work Graph at runtime with MCP

The most reusable idea here is treating Asana as a tool the agent calls at runtime, not a dataset you dump into a prompt. A naive approach exports everything to a file and stuffs it into the context window on every run. That bloats context, spikes cost, and goes stale the moment the data changes.

Instead, one agent connects to the Asana MCP server and the Asana API and asks live questions: which active projects might overlap with this request, which workspace goals are aligned with this request, and what the current team load looks like.

Two things make Asana a strong node in a system like this:

• Live operational context. A warehouse reports what happened historically to the agent. The Work Graph tells it what's happening now — who's committed to what, which initiatives are in flight, and where the load is. For an evaluation that has to weigh "should we take this on?", the live answer is the one that changes the decision.

• A governance model that already exists. Access in Asana is permission-aware by design. An agent querying the Work Graph operates within those boundaries instead of inheriting blanket access to a private store. The system keeps humans setting policy and agents doing the data work, with the actions traceable.

This is the same philosophy behind AI Teammates, viewed from the platform side. Shared context plus accountability, as laid out in our AI Agents Built for Teams.

The result: an intake task that comes back in about 20 seconds, enriched with an AI risk score, a resource-availability check, historical pattern analysis, and live workspace context with no manual steps.

The reviewer still makes the call, but now they make it with the full picture in front of them instead of on gut feel.

When you wouldn't build this

If you need Asana data to land in another system on a schedule, a native integration or an iPaaS connector (the kind already in the Asana app ecosystem) is simpler and more maintainable than custom agents. The architecture in this post earns its complexity only when you need runtime reasoning over multiple private sources at once.

Key takeaways

• Asana can be the human interface and a governed data source in the same agent workflow — webhook out, MCP query back in.

• Treat the Work Graph as a runtime tool the agent calls, not a static export you inject — it stays fresh and keeps context costs down.

• The open standards (webhooks, MCP) mean Asana connects to a technical agent system the same way any other source does.

• Keep humans on policy and agents on the data work, with traceability. That's what makes this safe to run on real enterprise data.

If you want to go deeper, watch the demo video below, the Asana webhooks guide is here, the developer platform docs are at developers.asana.com, and the repository can be found here.

Automate project intake with multi-agent AI using MCP, Google ADK, Cloud Run, and BigQuery

About the author

Kevin Blanco was a contractor Developer Advocate at Asana, where he worked on the developer platform: API documentation, guides, and enablement for the developers and partners building on Asana. He focused on agentic and AI use cases that show what the platform can do in real, technical systems. Before Asana, he spent over a decade building on Google Cloud as a Google Developer Expert, and he speaks internationally on Cloud, AI, and Architecture.