How one decision travels from a workshop to a build

Most delivery problems on an EPM implementation don't start in the software. They start with a decision that was made in a workshop, half-captured in someone's notes, changed in an email three weeks later, and then built from the old version.

EPM Agent is designed around that problem. The clearest way to show how is to follow one decision from the meeting where it was made to the build that implements it. The client and details below are fictive.

1. The workshop

In the third Planning design workshop for Northwind Retail, the finance team agrees that Facilities moves under Shared Services, and that Facilities costs are allocated across the Shared Services cost centres by headcount.

The Meeting Agent joins the Microsoft Teams call as a named participant everyone can see. Afterwards it keeps the captured transcript as evidence. It drafts a title, a summary, the decisions and the actions, and files them to the Northwind client and its Planning project. Where it can't tell who was speaking, the speaker is marked unknown, not guessed.

At this point it is still only a draft.

2. A person reviews it

Nothing an agent drafts becomes part of the project record until a person reviews it. The consultant who ran the workshop opens the summary, corrects the owner of one action, and approves the decision:

Facilities moves under Shared Services. Facilities costs are allocated across the Shared Services cost centres by headcount.

That decision is now a reviewed fact in Northwind's own knowledge base, linked to the workshop it came from. It sits inside a boundary that belongs to this client alone. An agent working for another client can't read it.

3. Someone asks about it

A week later, a developer building the forms asks the agent in chat: which cost centres roll up to Shared Services?

The agent searches Northwind's knowledge base, builds its answer from what it found, and shows its sources: the workshop and the approved decision. It doesn't write its citations from memory. It points to the records it actually retrieved, and code turns those into the references you see. A source the agent never fetched can't appear in the answer.

If the record has nothing on the question, the agent says so instead of filling the gap with something plausible. A general-purpose model knows a great deal about how Planning works. It doesn't know what this client agreed, and on an implementation that is the part that matters.

4. The decision changes

Three weeks later, the client's controller sends an email: the allocation driver should be floor space, not headcount. The consultant files the email to the Northwind project, and the agent proposes an update to the decision. Once a person accepts it, the new decision supersedes the old one.

The headcount decision isn't deleted. It stays in the record with its history, but it is marked as superseded and is never presented as current again. Ask the same question now and the answer cites the controller's email. Anything still undecided stays flagged as an open question until someone closes it.

5. The build

When it's time to build the allocation, the agent writes the business rule as a readable specification, from the reviewed decisions rather than from memory of a conversation:

"Allocate Facilities to Shared Services"
  app        Planning / OEP_FS
  runtime    prompts: Entity, Period
  fix        Scenario: Forecast, Version: Working
  allocate   Facilities_Cost
    to       ILvl0Descendants(SHARED_SVCS)
    driver   Floor_Space

A compiler turns that specification into the application's native format. The build is packaged for upload to the client's environments and checked by reading it back. The design document is authored from the same record, so it says floor space too, and it goes through its own review and approval.

6. A person approves

The last step belongs to a person as well. Nothing changes in a production environment until someone with the authority to approve it says yes.

The trail stays intact

At every step the decision carried its source with it. The workshop led to a reviewed fact, then to cited answers, a superseding email, a specification, and finally an approved build. Months later, when someone asks why the rule uses floor space, the answer is in the record with its evidence, not in someone's memory.

That is the whole idea behind EPM Agent: models select from evidence, code validates and transcribes, and the governed record holds the truth.

If you'd like to see it on the kind of project your team runs, book a walkthrough.