The Agent-Ready Tool Check
A free four-question check to run before you build an AI agent workflow on a project tool, plus the questions to put to its vendor or your IT team.
Use this before you design an agent workflow around a tool you don’t control: the task board, the document library, the reporting layer. Four questions show where the agent will struggle, and the answers point to one of three moves. Answer from the tool’s documentation, a short test, or a conversation with whoever administers the tool. You don’t need to read code.
The frame
One per tool, for one agent workflow.
Tool: [name]
Agent workflow: [what the agent needs from this tool]
1. Whole outcomes: can the agent ask for a finished answer ("all open risks with owners and mitigations") rather than one field at a time?
Answer: [Yes / Partly / No / Don't know] Evidence:
2. Full context in one request: can it get everything it needs about the project at once?
Answer: Evidence:
3. Safe retries: if a write is repeated after a timeout, does the tool avoid duplicate or conflicting records?
Answer: Evidence:
4. Change alerts: can the tool tell the agent when something changes, rather than the agent checking on a timer?
Answer: Evidence:
Move: [Bring the data together first / Ask the vendor or IT for a change / Build on it as is]
Questions to put to the vendor or IT: [list]
Have an AI draft the answers and the questions
I'm planning an AI agent workflow that uses the tool described below. Using the documentation or notes I've pasted, answer these four questions with Yes, Partly, No or Don't know, and quote the evidence for each:
1. Can an agent request a whole outcome rather than individual fields?
2. Can it retrieve full project context in one request?
3. Are repeated writes handled without duplicates or conflicting records?
4. Can the tool notify an agent when relevant data changes?
Then write up to five specific questions I should ask the vendor or our IT team, each naming the gap it closes. Where the documentation doesn't say, answer "Don't know". A connector existing does not count as a Yes on any question.
Agent workflow: [what the agent needs to do]
Tool documentation or notes: [paste]
Before you paste internal system details into a third-party AI tool, check your organisation’s policy for that tool.
Worked examples
The entries below are illustrative, with tool names left generic.
Task board for a weekly risk summary agent
Tool: The programme's task board
Agent workflow: Read every open risk and dependency across six workstreams and draft a weekly summary
1. Whole outcomes: No. Risks come back one record at a time; owners and mitigations are separate calls.
2. Full context in one request: No. Six workstream boards, each queried separately.
3. Safe retries: Don't know. Not relevant yet, the agent only reads.
4. Change alerts: Partly. Webhooks exist for status changes, not for new comments.
Move: Bring the data together first. A nightly export of all six boards into one file the agent reads.
Questions to put to the vendor or IT:
- Can we get one export of open risks with owners and mitigations across boards, on a schedule?
- Do webhooks cover new comments, or only status changes?
- Does the connector you've published return whole records, or the same single-field calls?
Document library for a status drafting agent
Tool: The project document library
Agent workflow: Read the latest workstream updates and save a draft status report back to the library
1. Whole outcomes: Partly. Search returns whole documents, not the sections the agent needs.
2. Full context in one request: Yes, for one folder.
3. Safe retries: No. A repeated save creates a second copy with a new name.
4. Change alerts: Yes, for new and edited files.
Move: Build on it as is for reading. For writing, the agent saves to one fixed draft file a person renames, so a repeat overwrites rather than duplicates.
Questions to put to the vendor or IT:
- Can a save be set to overwrite a named file rather than create a copy?
- Can the agent's account be limited to the one project folder?
Notes on the questions
A connector gives access. It lets an agent reach the tool. How many requests the work takes, and what happens on a retry, stay the same.
Safe retries matter more for agents than for people, because agents meet more retries after timeouts and errors.
Bring the data together first is often the fastest move: a single file or snapshot the agent reads, refreshed on a schedule, in place of dozens of requests per run. Someone then owns keeping it current.
Check it before you build
- Is every Don’t know either answered or turned into a question for the vendor or IT?
- Does the move you chose deal with each No?
- If the agent will write to the tool, is question 3 answered with evidence?
- Has whoever administers the tool seen the questions?
When it does not apply
If the agent only reads a few exported files you give it each time, this check adds little. Run it when an agent will connect to a live tool, especially one it can write to.
What this feeds
The answers set what goes under inputs and limits in the agent version of the Outcome Brief. Write access and its limits belong in your agent governance charter. Before go-live, question 3 becomes an edge case in the Agent QA Checklist.