Reads operating context
Marcus is being designed to connect the customer, work, people, records, and policies around a request.
Planned intelligence layer
Marcus AI · Designed around the operating thread
Intelligence that knows when to recommend, wait, or ask.
Marcus is being designed to read operating context, surface useful recommendations, respect authority and policy, separate evidence from recommendation, and keep people in control of consequential decisions.
Planned intelligence layer · No live AI call or autonomous action in this preview
AmbientPlanned intelligence layer
Marcus is shown as a calm, planned intelligence layer. This public preview does not monitor a business or read live records.
Marcus recommendation modelNot live
Context → evidence → recommendation
Read the threadExplain the reasonAsk before acting
Planned by design. Marcus will inherit the same authority, policy, approval, and audit boundaries as the operating system.
What Marcus is being designed to do
Useful intelligence starts with accountable context.
Marcus is planned as a reasoning layer inside TaskPulse, not a separate assistant that loses the business boundary. Its job is to make the thread easier to understand and the next decision easier to review.
Surfaces a recommendation
The planned layer will explain the next useful step instead of hiding a conclusion behind a score.
Respects authority and policy
Recommendations will carry the same identity, organization, authority, and policy boundaries as TaskPulse.
Keeps humans in control
People will decide when a recommendation becomes a consequential action. Autonomous actions are planned, not live.
Illustrative preview · Not live
A recommendation should show its work.
This static panel demonstrates the shape of a future recommendation. It does not call an AI service, inspect a record, draft a message, or take an action.
Illustrative preview · Not live
Illustrative operating thread · Service follow-up
A follow-up needs a clear owner
Evidence
The next responsible step becomes visible after the request, authority context, and supporting record are connected.
Recommendation
Ask the assigned owner to confirm the customer follow-up window before any message is sent.
Before a consequential action
Marcus must earn the right to move the thread.
A future recommendation can be useful without becoming an automatic action. The planned boundary keeps the human decision, the operating policy, and the audit record visible.
Authority
The acting identity and organization boundary must support the decision.
Policy
The relevant business rule or operating policy must be clear.
Approval
A human with the right authority must approve consequential action.
Audit
The approved change must carry a protected record of what happened.
Planned consequential actions require the right authority, policy, approval, and audit context. Autonomous execution is not available in this public preview.
A staged roadmap
Build intelligence in accountable steps.
The roadmap separates the foundation that exists around the business from the Marcus layers still being designed.
- 01Current foundation
Context
Identity, ownership, workspace, customer, authority, and audit foundations give Marcus a boundary to design around.
- 02Planned
Recommendation
Surface a useful next step with the evidence and uncertainty that support it.
- 03Planned
Approval
Route consequential choices to the person with the right authority and policy context.
- 04Planned
Action
Carry approved actions through controlled writes with a clear record of what changed.
- 05Planned
Learning
Use reviewed outcomes to improve future recommendations without erasing accountability.
Keep exploring
See the foundation Marcus will be built around.
Review the product demo for the current operating foundation, or follow the full model from identity and ownership through planned intelligence.