LinkedIn
ProjectMate is a Salesforce delivery accelerator. It takes discovery material and, step by step, turns it into the artefacts a delivery team needs: requirements, clarifications, epics, user stories with Given/When/Then acceptance criteria, build tasks and test cases.
It is built as a team of agents. A Lead Agent is the user's single point of contact and hands work to specialists: a BA Agent today, with an Architect Agent to follow.
How it works:
- Agents analyse the discovery material and propose - they never change the backlog on their own
- Where something is unclear, they raise a clarification and ask a person to decide
- When a decision is made, the BA Agent assesses its impact on the backlog and prepares a formal change proposal
- The proposal is applied only after a person explicitly confirms it, and the BA Agent then revalidates the result
- Only then does the work move on to the next specialist
On a sample discovery document for a fictional car-rental company, covering Sales, Service and Experience Cloud, the BA stage produced 105 requirements, 14 epics, 105 user stories, 171 acceptance criteria and 20 clarifications for review.
Status: the Lead and BA Agents are built and tested; the Architect Agent is next. Test cases are planned as a simple conversion of the Given/When/Then acceptance criteria rather than a separate agent.
One run, one record of state
Everything for a run sits on a Generation Run record: the discovery analysis, the staged backlog, and the review state, which holds the clarification decisions, change proposals and revalidation results. The data model is deliberately lean, with ten custom objects and no separate object for proposals.
Confirming the exact change
When a person resolves a clarification, the BA Agent works out which parts of the backlog it affects and prepares a typed proposal: an ID, the before and after values, the reason and a digest, a fingerprint of the proposal. The person confirms that exact proposal. The apply action needs the ID, the digest and the person's confirmation, so what is applied is exactly what was approved.
In the demo run, one clarification about payment processing changed a single acceptance criterion, and only that criterion changed. The BA Agent then revalidates the backlog, and only a passed revalidation lets the run move on to the Architect stage.
Lessons from agent activation
The first BA Agent repeatedly failed to activate because of invalid action metadata, so I rebuilt it. The lessons are worth sharing: record ID inputs must use the record ID type, not the object type; whole-number and decimal outputs need their matching types; and the standard messaging variables must stay in the agent even when they are unused and validation reports them as unused. I now activate an empty agent first and add one action at a time.
What I would tell another team
- Keep the run's state in Salesforce so every agent works from the same record
- Make a person confirm the exact change, not a description of it
- Revalidate before handing work to the next agent
- Activate early and add actions one at a time
I design, build and review agents like this as an Agentforce consultant in the UK.