Resource planning fails when the spreadsheet is stale before the meeting starts. A program manager re-keys Asana milestones, Monday sprint loads, and Workday headcount into a tab nobody trusts. Dock removes the re-key. An agent reads the three systems on demand, drafts an allocation, and posts it as a row the resource manager either approves or rewrites. The agent's identity, the source URLs, and the reviewer decision all live on one row. This is the Dock for project management building pattern applied to capacity.
Asana, Monday, and Workday stay the system of record for the raw data. Dock is the system of record for what the AGENT INTERPRETS. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.
The surface: a Resource Plan table
| Initiative | Asana / Monday demand | Person | Workday capacity | Proposed alloc | Agent | Reviewer decision |
|---|---|---|---|---|---|---|
| Checkout v3 | Asana proj 8821, 6 epics, Q3 | Priya R. | 32h/wk avail, 80% billable | 24h/wk for 9 wks | pm-agent@dock | Approved by L. Chen, 2026-05-29 |
| SOC2 evidence | Monday board 414, 11 tasks | Marcus T. | 20h/wk avail (PTO wk 24) | 16h/wk for 6 wks, gap wk 24 | pm-agent@dock | Adjusted: shift wk 24 to A. Park |
| Pricing redesign | Asana proj 9102, kickoff Jun 10 | Unassigned | 3 candidates with 12-18h | Hold, ask Lila for ranking | pm-agent@dock | Pending |
Each row links out to the Asana project, the Monday board, and the Workday worker profile. The agent column is a real identity, not a service account, which matters for the reasons in Cloud 2.0 for product and the agent collaboration primer.
The workflow
Monday morning, pm-agent runs the plan job. It fetches open epics from Asana and Monday, filters to the next 12 weeks, and totals demand hours by skill. It then queries Workday for each candidate's availability, PTO calendar, and billable target. It drafts one row per initiative with a proposed allocation and a confidence note. The resource manager opens the table, sees the three source links per row, and either approves, rewrites the hours, or reassigns. The decision writes back to Asana as a task assignment and to Monday as a person column update. Workday stays read-only. Every write carries the agent identity defined in the agent identity model.
Why it matters
The plan is auditable. Six months later, finance can ask why Marcus was on SOC2 at 16 hours and the row shows the Workday capacity snapshot, the Asana demand, the agent's draft, and L. Chen's adjustment. The plan is also fresh. The agent re-reads Workday before each weekly run, so a mid-quarter hire or a new PTO request changes next week's draft without anyone re-keying. Resource managers stop being data janitors. They review and decide. This is the same pattern that runs in Dock for People Ops for headcount, with the reviewer role moved from HRBP to RM.
External grounding. Asana defines capacity planning as "figuring out if you have the right resources to meet your project's needs" (Asana, 2025). Workday Adaptive frames workforce planning as modeling "hiring, transfers, and retention plans with driver-based assumptions" with instant cost impact (Workday, 2026). Dock connects those two definitions with an attributed review row.
Try the resource-planning workflow on your own Asana, Monday, and Workday data. Start a Dock workspace and connect the three systems in under ten minutes.
FAQ
Does the agent write to Workday? No. Workday is read-only in this workflow. The agent reads capacity, PTO, and billable targets. Writes go to Asana task assignments and Monday person columns only. Capacity changes still flow through the HRBP in Workday.
What if the resource manager rejects the draft? The rejection is the row's decision. The agent does not retry. It logs the rejection reason on the row, and the next weekly run uses the manager's adjustment as a constraint for the following week's draft.
How is the agent's identity tracked? pm-agent has its own principal, its own OAuth scopes per platform, and its own audit trail. It is not a service account borrowed from a human. See agent identity for the full model.
Can two agents propose conflicting allocations? Yes, if two are connected. The Dock row stores both drafts as separate proposals and the reviewer picks one. The losing draft is retained for audit, not deleted.