On this page

How TensorPM Works

In short

TensorPM is not another tool you type tasks into. It is a project agent that maintains a complete, current, human-confirmed picture of your project and uses it to support your steering decisions. The model behind it is Understand -> Steer -> Execute. First a reliable project picture takes shape, then analysis and recommendations follow, and only after that can the project agent take on concrete work.

This article does not list buttons. It explains why the app works the way it does. Once you have read it, every other article makes sense.

The core problem: project knowledge is scattered

In a simple project, the current state fits in one head. In a complex project, it fits in none. The knowledge spreads across emails, meeting minutes, drawings, quotes, chat messages, phone calls, and whatever individual people happen to remember.

How this shows up in daily work

  • A deadline moves in an email to three people. The schedule still shows the old date.
  • A decision is made in a meeting. It reaches the minutes, but nobody carries it into the budget.
  • A change order is promised verbally. Four weeks later nobody remembers who promised what.
  • Somebody asks how the project is doing, and you need half a day to assemble an answer.

This is not a discipline problem. The state is simply never complete in one place. Every statement about the project is therefore a reconstruction, and every reconstruction costs time and can be wrong.

What TensorPM changes about it

TensorPM keeps the project state in one place: the project context. The project context is the set of facts you have confirmed, meaning goal, scope, success criteria, dates, budget, requirements, milestones, risks, the people involved, and the decisions that have been made.

The word that matters is "confirmed". The project context does not fill itself, because then nobody could trust it. It fills through a cycle in which you are the control point. The section after next describes that cycle.

The three layers

TensorPM has three layers. They build on each other, and the order is not a matter of taste.

Layer 1: context as the foundation

The bottom layer is confirmed, current project knowledge. You find it in the Context view, split into the sub-tabs Info, Profile, Resources, Content, Planning, and Risks.

The Info tab is the overview: today's focus, the current bottleneck, a risk summary. The other tabs hold the substance that overview is built from.

The Info tab in Context summarizes focus, bottleneck, and risks, showing where the project state is heading.
The Info tab in Context summarizes focus, bottleneck, and risks, showing where the project state is heading.

This is more than a document. The same structured information feeds everything above it: the the analyses, the Timeline, the project agent's answers, and the data external tools are allowed to read through an interface. If the context is wrong, everything above it is wrong. That is why it is the foundation and not one feature among many.

The practical rule is: when the project changes, the context changes. A new decision must not be left sitting in an email.

Layer 2: steering as the core

The middle layer is the actual product value. It answers the two questions that really occupy a project lead: what is the bottleneck right now, and what comes next.

That is what Review project in the Pulse view is for. One run produces four analyses:

  • Context Analysis: is important information missing, or does it contradict itself?
  • Strategy: do the current choices actually serve the project goal?
  • Coverage Analysis: does the planned work genuinely cover the goal and the success criteria?
  • Execution: what is urgent, blocked, late, or on the Critical Path?

The results land in two places. The first three become suggestions in the Suggestions card of Pulse, each naming an observation, its impact, and a proposed step, with Apply, Discuss in chat, and Dismiss. The execution analysis becomes the Order tab inside the Action Items view, which lays the work out along the critical path.

Important: There is no separate Guidance view in the sidebar any more, and no AI+/User mode switch for it. What still exists as a pair of AI+ and User values is the project status in the health card and the priority of a single action item.

This is decision support, not a decision maker. Every suggestion names what it is based on. Check the evidence, discuss the recommendation, and pick the action that fits the real situation. Details are in Suggestions & Order.

Layer 3: execution as an extension

The top layer is optional. Here the project agent does concrete work: it drafts emails, prepares calendar changes, produces analyses, and writes documents, spreadsheets, or presentations. It can also hand suitable technical work to local coding agents such as Claude Code, Codex, or GitHub Copilot.

The project agent panel next to the view: the chat works with the full project context.
The project agent panel next to the view: the chat works with the full project context.

TensorPM stays fully usable if you do all execution yourself. Delegation is an extension, not a requirement. More on this in Project Agent, Chat & Quick Actions and in Skills.

Why the order matters

Many AI tools start at layer 3. They write a good email but do not know the project. The result reads smoothly and is still wrong, because the foundation is missing.

TensorPM starts at layer 1. An agent that knows the goal, scope, dates, commitments, and risks gives different advice than one that only sees the last ten messages. The effort you put into confirmed context pays off in every analysis and every deliverable above it.

The cycle: from signal to confirmed context

The heart of TensorPM is a cycle with five stations. It keeps the project context current without letting it grow out of control.

Step 1: a signal arrives

A signal is one piece of incoming information that might matter to the project: an email, an uploaded document, a file in the project folder, or a message an external tool delivers.

Signals come from these sources:

  • the Email Connector (a classic mailbox over IMAP and SMTP)
  • Microsoft 365
  • Local email (Apple Mail on your device, with no password and no server access)
  • files and documents you add to the project
  • external agents delivering signals through a tool connection; the filter calls these MCP Signals

A connector is a saved connection to such a source. Not every connector delivers signals: Telegram is a chat bridge and Local calendar is calendar access. Neither one deliberately feeds this cycle.

New signals collect behind the mailbox icon in the header. The panel has three views: Incoming Signals, Proposed Changes, and Ignored Signals.

The incoming signals panel shows what has arrived since you last looked and what has already been proposed from it.
The incoming signals panel shows what has arrived since you last looked and what has already been proposed from it.

Optionally, TensorPM screens incoming connector emails for relevance first. The setting is called Auto Relevance Check for Intakes. It moves obvious noise to Ignored Signals with a reason. Important: this check only sorts. It never changes the project context, and you can restore any signal it filtered out.

Step 2: the Distiller proposes individual changes

The Distiller is the review step between a signal and the project context. It reads a signal and proposes individual, clearly bounded changes. Each proposal is small enough that you can accept or discard it on its own.

A single site email can produce four separate proposals, for example:

  1. The milestone "structural work complete" moves by two weeks.
  2. A new requirement for the fire door is added.
  3. A risk "window delivery delay" is added.
  4. A commitment by the client is recorded as a decision.

That granularity is deliberate. If a signal could only be accepted as a whole, you would have to choose between "take everything including the badly worded parts" and "take nothing". Both are bad for the quality of the context.

Step 3: you decide proposal by proposal

Every proposal arrives as its own card. Each card shows exactly what would change and where the information came from. You decide per card:

  • Approve: the proposed value replaces the previous one.
  • Append: the proposed text is added instead of replacing. Useful for lists and collections.
  • Skip: the card stays undecided and you come back to it later.
  • Reject: the card is discarded.

You can correct the text before you decide. At the end you confirm the batch with the Apply {{count}} items button. What you decided shows up as the badges Approved, Appended, Rejected, and Skipped.

Before you approve a card, four checks are worth the time:

  1. Read the full proposal, not just the heading.
  2. Check the source and the affected project.
  3. Fix anything vague or truncated.
  4. Approve only the exact change you want.

Step 4: only confirmation changes the context

A proposal is not a change. Until you approve or append a card, the project context stays as it was. There is no path in the app on which an incoming signal changes the project context by itself.

Every confirmed change lands in Trail, in the Changes tab. There you see the old and the new value, the timestamp, and the origin. Durable commitments are kept separately in the Decisions tab, with a status and a supersede chain.

The Trail view shows the previous and the new value for every change, along with its origin.
The Trail view shows the previous and the new value for every change, along with its origin.

That traceability is the reason the cycle makes sense at all. For any statement in the project context you can trace who confirmed it, when, and on what basis. More on this in Files and Trail.

Step 5: The analyses work with the new state

As soon as the context is updated, everything above it works with the new state. A moved deadline moves the critical path. A new risk shows up in the risk summary. An added requirement changes the coverage analysis.

That closes the loop: new information arrives, becomes proposals, gets confirmed by you, becomes part of the context, and the steering layer recalculates.

Nothing changes silently in the background

This is the app's most important promise, so here it is explicitly, including the edge cases.

What runs on its own and what it does

Four things run in the background. None of them changes your project context:

Feature What it does Default
Auto Relevance Check for Intakes moves obvious noise to Ignored Signals, restorable off
Automatic AI Prioritization calculates the AI priority of a new or edited action item on
Daily Project Status Review produces one AI assessment of status and progress per day, kept separate from the status you set yourself off
Proactive Project Check-ins reviews active projects on a schedule and sends a system notification with a report off, Pro and Business only

All four live under Settings -> General and can be switched off. Check-ins are described in Project Check-ins.

What the project agent does in chat when you ask it to

One distinction matters so nothing surprises you: when you instruct the project agent directly in chat, for example "set the new end date" or "add this person", it carries that out without showing you an approval card first. That is intended, because you just asked for it. The difference from the cycle above is origin: a signal from outside gets reviewed, your own instruction gets executed.

Those changes also appear in Trail afterwards, with their origin. So you can always check what the agent changed on your behalf.

Why this separation matters

A project context that fills itself becomes useless fast. A misunderstanding in an email turns into a project decision. A polite phrase turns into a commitment. A quote you never accepted stands in the budget as a fact.

The moment that happens once, you stop believing the whole project picture, and then every analysis built on it is worthless too. Human confirmation is therefore not a brake but the condition for the context being worth anything. For the same reason, external agents connecting through an interface may only deliver proposals and can never write into the project context directly.

Every outbound action needs its own approval

Changes to the project context stay in the house. A sent email does not. So anything that leaves the project or changes something outside TensorPM requires its own visible approval. Details are in Connectors and Approvals.

Sending email

The project agent can write a draft but not send it. The draft appears as a card in chat, with recipients, subject, the full body, attachments, and the connector used. Only Approve & Send dispatches it. Until then the status reads Awaiting approval.

If you edit the draft, the old approval expires and you have to confirm again. Otherwise something other than what you read could go out between your review and the send.

Creating and changing calendar events

Calendar changes work the same way. The agent prepares the change, you see it in detail, and only Approve & Apply writes it to the calendar. This applies to Microsoft 365 as well as to Local calendar on the Mac. The local calendar can read, create, and update, but it cannot delete and cannot change attendees.

External tools via MCP

MCP is a tool connection that lets the agent use programs outside TensorPM. When it calls such a tool, a Permission requested card appears with the tool name and what it intends to do. If the call modifies data, it is additionally marked Changes data.

You pick Allow, Don’t allow, or Always allow. Always allow applies permanently to that server, so make that decision once in a calm moment rather than five times under time pressure. Read-only calls that declare themselves as such go through without a prompt.

Skills that run programs

A skill is an extension that lives in the project folder and brings domain knowledge or executable code. Executable skills require Approve skill. The approval is bound to the exact content and to the permissions requested. If a file changes or the skill asks for more rights than before, the approval expires and you are asked again. See Skills.

Why approvals are not bundled

Clicking "allow everything" once would be convenient. It would also be worthless. An approval is a control only when it refers to one concrete action you can see in front of you: this email, to these recipients, with this text. A blanket approval is not a control, it is a signature on a blank page.

What stays local and what goes to the cloud

TensorPM is local-first. That means the app works fully without internet, and the cloud is an addition, not a prerequisite.

Always local

  • the project database on your device
  • the project folder with all files
  • all connector settings, exactly as the Configure Connectors panel puts it: "Settings are local-only."
  • connector passwords and credentials, held in your operating system's secure store, which the app calls Keyring
  • your own AI keys and the credentials of local coding agents
  • file contents, even with cloud sync active

A local workspace never leaves your device. A workspace is the bracket around a group of projects.

Only with cloud sync

Cloud sync is a feature of the Pro and Business plans. When it is active, TensorPM syncs the project data of a cloud workspace between your devices and the people in the workspace.

Two points about it:

  • The data is End-to-End Encrypted. Without ready device keys, cloud sync does not start at all. The server sees encrypted content, not your projects.
  • File contents are not sent along. On a second device you see the information about a file, but not automatically the file itself.

More on this in Cloud Sync, Workspaces, and Encryption.

What goes to the AI provider

This is a separate path, independent of cloud sync. For an AI to answer, the slice of the project it concerns has to be sent to the AI provider. Where it goes depends on your setting:

  • TensorPM AI: the request runs through the TensorPM service and consumes AI Credits.
  • Your own keys (BYOK): the request goes straight to your provider, not through TensorPM. This is reserved for the Business plan.
  • Local AI: with Ollama, LM Studio, or vLLM the AI request stays on your machine too.

Without an AI provider TensorPM still works, just without the AI-supported parts. See Account and AI Modes.

CDPM: the method behind the product

What CDPM means

CDPM stands for Context-Driven Project Management. Its one basic assumption is this: the quality of every project decision depends on the quality of the available project context.

Three working principles follow from that:

  1. There is one shared, confirmed basis instead of many half-current copies.
  2. That basis stays current because new information enters through a governed cycle.
  3. Every recommendation and every deliverable rests on that basis and names its evidence.

TensorPM is the software implementation of those principles. The project context is the shared basis, the Distiller cycle keeps it current, and every analysis rests on it.

How CDPM relates to your method

CDPM extends the method you work with. It does not replace it and does not call it into question.

Scrum, waterfall, SAFe, PRINCE2, lean construction, or a grown in-house method all answer the same question: how do we organize the work? They set roles, rhythms, artifacts, and approval paths. CDPM answers a different question: how does everyone involved know, at any moment, where the project really stands?

Both questions are necessary, and they do not get in each other's way:

Your method What CDPM adds
Scrum The product backlog and sprint goals stay. The project context supplies goal alignment, dependencies, and risks beyond the sprint.
Waterfall Phases and milestones stay. The cycle makes sure plan changes between phases do not disappear into email.
SAFe Program increment and cadence stay. The project context gives every train the same set of facts.
PRINCE2 Business case, stage gates, and roles stay. The trail documents decisions and commitments with their origin.
In-house method Everything stays as it is. The project context fills the gap between the dates on which you report anyway.

In practice that means you do not have to change your processes to use TensorPM. You get a layer underneath your process that holds the state.

An example

A construction project runs classically, by schedule and work phases. On Tuesday the site manager gets an email saying the windows will arrive four weeks late.

Without a shared context this happens: the email sits in the mailbox. The schedule stays as it was. At Thursday's standing meeting nobody remembers it. Two weeks later the delay surfaces, now together with a knock-on delay in interior work.

With TensorPM nothing about the process changes. Still a schedule, still the standing meeting. But: the email becomes a signal, the Distiller proposes a date shift and a risk, the site manager confirms both in a minute, and on Thursday the Info tab says interior work is the new bottleneck. The method is the same. The facts are better.

Which view answers which question

The left sidebar in a project is organized by question, not by data type. This overview tells you where to look and where the detailed article is.

View Answers the question Covered in
Context What is this project about, and what is the frame? Project Structure and Context
Pulse What is the bottleneck right now, and what comes next? Suggestions & Order
Work How is the work broken down, and who accepts it? Work Packages and WBS
Actions What concretely has to be done, by whom, by when? Action Items
Timeline When does what happen, and what depends on what? Navigation and Views
People Who is involved, and who decides? Resources and People
Budget What does it cost, and what is ordered or delivered? Materials and Procurement
Files Which documents and results belong to it? Files and Trail
Trail What changed, when, and on what basis? Files and Trail

Two notes on this:

  • The Work Packages area appears only when the work breakdown structure (WBS) is enabled for the project. You enable it under Settings -> General -> Work Breakdown Structure.
  • The Budget view has two tabs: Budget and Material. The Material tab covers procurement with its own status model and is described in Materials and Procurement.

Not in the sidebar but just as important: the mailbox icon in the header for new signals, and the project agent panel you toggle with Show AI Panel.

A weekly steering routine

The cycle works best when it has a fixed slot. On a running project this routine takes about twenty minutes:

  1. Go through new signals and decide the Distiller's proposals.
  2. Skim the Changes tab in Trail: what changed since last week?
  3. Carry open points from dates, budget, and risks into Context.
  4. Update blocked, late, and completed action items.
  5. Click Review project in Pulse, or work through the suggestions already there.
  6. Decide the two or three interventions that actually move something.
  7. Hand concrete work to the project agent where it pays off.
  8. Record durable commitments as decisions instead of leaving them in chat.

The first point is the important one. A cycle whose proposals nobody decides does not keep the context current.

Terms you will meet

  • Project context: the confirmed facts and constraints of the project
  • Signal: one piece of incoming information that might matter to the project
  • Connector: a saved connection to an external source, such as a mailbox or a calendar
  • Distiller: the review step that turns a signal into individual proposed changes
  • Suggestion: one analysis finding with its impact and a proposed next step
  • Project agent: TensorPM's AI, which reasons with the whole project context
  • Trail: the history of changes and decisions, including their origin
  • Approval: your explicit confirmation for an outbound action
  • Workspace: the bracket around a group of projects, local or in the cloud
  • CDPM: Context-Driven Project Management, the method behind the product
  • MCP: a tool connection through which another AI tool can read project data or deliver proposals
  • A2A: a conversation interface through which another AI tool asks TensorPM to analyze or act

You do not need MCP or A2A for daily project work. They matter once you connect TensorPM to other AI tools. A full list is in the Glossary.

Frequently asked questions

Do I have to fill in the whole context at once? No. Start with goal, scope, and dates. The rest grows through the cycle, because your project routine produces signals anyway.

What happens if I do not decide any proposals for a week? Nothing is lost. Signals and proposals sit there until you decide them. The project context stays at the old state that long, and the analyses calculate with that old state.

Can I use TensorPM without AI? Yes, with limits. Context, action items, dates, budget, people, and trail work without an AI provider. The Distiller and the four analyses need one. Without them you still have the List and Board views of your action items, but no suggestions and no Order tab.

Does the AI change things in my project without me noticing? Never from incoming signals. On your direct instruction in chat it does, and that then appears in Trail. In the background only the four features listed above run, and none of them changes the project context.

Does TensorPM send emails on its own? No. The project agent can prepare a draft. Nothing goes out before Approve & Send.

Do I have to change my project method? No. CDPM extends your method, whether you work by Scrum, waterfall, SAFe, PRINCE2, or an in-house method of your own.

Is my project data in the cloud? Only if you use a cloud workspace with Pro or Business, and then it is End-to-End Encrypted. A local workspace stays on the device.

Next steps

Previous
Project creation wizard
Next
Plain-language glossary
Was this page helpful?