Figr’s Context Pod gets an important part of the problem right: it lets a team bring screens, files, websites and written notes into one place so the agent can begin with the product’s actual context.
My first instinct was that Context Pod needed a built-in Markdown editor.
That turned out to be the shallow observation. Figr already has an in-product note editor.
The more interesting question appeared after I saved a note as a source:
What happens after the context is added—and the product changes?
the work splits in two
There are two different jobs hiding inside “context management.”
1. Collecting context
Capture screens. Upload documents. Add links. Write notes. Give the agent more material to reason from.
2. Maintaining product truth
Know which decision is current. Understand what has been superseded. Resolve contradictions. See who owns a source. Know which generated artefacts depend on it.
Figr already makes the first job feel approachable. The second job becomes increasingly important as a Context Pod survives multiple product decisions.
what I observed
In the workflow I tested, a saved note became a source that I could reopen or remove.
I couldn’t find an obvious way to revise that note, mark it as outdated, show that another document superseded it, or see which outputs were relying on it.
That does not mean these capabilities do not exist elsewhere in Figr. It is only what was visible in the flow I used.
But the interaction surfaced a larger agentic UX question.
the problem isn’t missing context
Imagine a team adds three individually valid sources:
- January PRD: work email is required
- March product decision: personal email should be allowed
- April shipped flow: both are accepted
Nothing here is necessarily wrong.
The problem is that the documents carry different levels of authority. A teammate may understand the history because they attended the discussions. An agent only sees available context and must infer which source represents the current product.
More context can therefore create a stranger failure mode: an output that is well-grounded, coherent and still based on the wrong truth.
why this matters for agentic products
Traditional software retrieves information.
An agent uses that information to make decisions and produce new work.
That changes the responsibility of the context layer. It cannot only answer:
“What material is available?”
It eventually needs to help answer: “What should the agent currently believe?”
This is where context starts looking less like a folder and more like a product model.
The useful signals may be surprisingly small:
Current— this source represents the active decision
Superseded by — use the newer decision instead
Owner — this person or team can resolve ambiguity
Conflict — two sources disagree on a consequential fact
Affected outputs — these canvases or artefacts used this assumption
The interaction does not need to become a document-management system. The value is making authority visible enough that the human and agent can reason together.
the product question
Context Pod already helps Figr understand more about a product.
The question I’m left with is whether its longer-term value is primarily in holding more material or in maintaining a trustworthy model of what the product currently is.
That second direction could create a meaningful loop:
A product decision changes → Figr identifies the affected context → the team confirms the new truth → dependent work can be reviewed.
The human still controls the decision. The agent makes its consequences visible.
the short version
Adding context is not the hard part for long.
Keeping it current, authoritative and safe to act on is.
I’d be curious how the Figr team thinks about this today: when sources inside a Context Pod disagree or age, how should the product decide what the agent should trust?
Understand deeply. Design only what matters.