Project Solara Shows AI Agents Are Moving Off the Laptop

Microsoft's Project Solara is one of the more interesting signals from Build 2026 because it moves AI agents out of the usual app and laptop frame.

Microsoft describes Solara as a chip-to-cloud platform for "agent-first" experiences and new device form factors. The idea is not simply to put a chatbot on another screen. It is to create devices that are shaped around agents, tasks, context, and enterprise controls. Coverage from Tom's Hardware, TechRadar, TechRepublic, and others highlights the same shift: agentic AI is moving toward purpose-built hardware, edge context, cloud state, and workplace devices.

For product teams, that is not only hardware news. It is backlog news.

When an agent runs across a badge, a desk device, a workstation, a cloud service, an identity layer, and a set of enterprise controls, the story is no longer "add AI assistant." The story includes context capture, permissions, device behavior, privacy, observability, support, rollout, and recovery.

Planning poker needs to estimate that operating model.

Agent-first devices make hidden work visible

Software teams often underestimate AI work because the demo looks simple. A user asks for help. The agent responds. The interface feels clean.

Agent-first devices make the hidden parts harder to ignore.

A device may have microphones, cameras, sensors, location, identity, network state, local compute, cloud handoff, and persistent memory. It may be used by frontline workers, office teams, support staff, clinicians, retail teams, or field technicians. It may act in a workflow where mistakes have real operational consequences.

That means a story is not ready just because the prompt is clear.

Before estimating, ask:

• What context can the device collect?
• Which context is necessary and which is excessive?
• Who can access the captured data?
• What runs locally and what goes to the cloud?
• What happens when the network drops?
• What can the agent do without confirmation?
• How does the user know what the agent saw, heard, stored, or changed?
• What logs prove what happened later?

If the story does not answer those questions, the estimate should include the uncertainty.

Edge context changes story points

Traditional web work usually assumes a stable input surface: browser, request, database, response. Agent-first devices expand the input surface.

A camera view can be ambiguous. A microphone can capture bystanders. A location signal can be stale. A device can be shared by a team. A frontline worker may need hands-free interaction while moving through a physical environment. A cloud agent may have more state than the small device in front of the user.

Those details change the estimate.

A three-point story might become eight points when it adds:

• Sensor permission design.
• Consent and notification states.
• Offline and low-connectivity behavior.
• Device enrollment.
• Identity and role checks.
• Edge-to-cloud handoff.
• Audit logging.
• Support diagnostics.
• Safety review.

Planning poker is useful here because different roles will notice different risks.

The product manager may see a simpler workflow. The engineer may see state synchronization. The designer may see ambiguous user feedback. The security reviewer may see data exposure. The support lead may see a debugging problem.

That spread is not noise. It is the planning signal.

AI agents need a definition of allowed action

Microsoft's Build 2026 announcements also emphasize controls and trust. The official Build blog points to an Agent Control Specification for standardizing where and how controls apply in the agent loop, and ASSERT for policy-driven safety evaluation. Microsoft's Security Blog describes controls that can detect, block, and audit sensitive data before it reaches an agent.

That should change sprint planning language.

For every agent-first device story, the backlog item should say what the agent can do:

• Read only.
• Recommend an action.
• Draft an action.
• Execute after user approval.
• Execute automatically within limits.
• Escalate to a human.
• Stop and explain uncertainty.

If the story says only "agent helps the user," the team cannot estimate safely. Help is not a permission model.

Use planning poker to reveal control gaps

Imagine a team estimating a Solara-style device workflow for a retail associate.

One person votes 3 because the agent only needs to answer questions about inventory. Another votes 13 because the device can hear customer conversations, identify store context, query systems, suggest actions, and maybe write updates to a workflow.

Both voters are seeing real work. They are just estimating different boundaries.

The low voter is assuming:

• Read-only access.
• Existing inventory APIs.
• Simple conversational UX.
• No customer data stored.
• No offline mode.

The high voter is assuming:

• Sensitive audio or image context.
• Identity and role-based access.
• Cloud state that must be auditable.
• Fallbacks when context is wrong.
• Support tooling for field issues.
• Review of what the agent is allowed to change.

Do not average those numbers. Ask what control model each voter assumed.

The final estimate should follow the control model, not the demo.

Split device-agent stories before sprint commitment

Agent-first work gets large because teams combine hardware context, model behavior, cloud systems, permissions, and user experience into one ticket.

A healthier backlog splits the work:

• Define the user outcome and environment.
• Map context the device can collect.
• Decide the data and permission boundary.
• Build a read-only agent path.
• Add human approval states.
• Add audit logging and diagnostics.
• Validate safety and privacy cases.
• Roll out to a small group.
• Expand allowed actions after evidence.

Each ticket can then be estimated with clearer risk.

This also makes sprint reviews better. The team can show a read-only workflow, learn from it, then add responsibility gradually instead of betting the sprint on an all-at-once agent.

Write Jira notes that preserve agent assumptions

The estimate should leave a short trace of what the team believed.

Useful notes might say:

• "Five points because the device is read-only and existing identity checks apply."
• "Eight points because audio context needs consent, redaction, and audit logs."
• "Split before sprint: sensor capture, cloud state, and workflow write access are separate risks."
• "Agent may recommend actions; user approval required before writes."
• "Estimate includes offline fallback and support diagnostics."

These notes are valuable for future planning. They also help AI tools summarize the ticket without erasing the boundaries humans agreed on.

A better readiness checklist for agent-first work

Before voting, ask the team to check six areas.

First, environment. Where will the device be used, and what physical context matters?

Second, data. What can be captured, stored, transmitted, or inferred?

Third, identity. Who is the user, what role do they have, and how is that verified?

Fourth, authority. What can the agent read, draft, trigger, or change?

Fifth, evidence. What logs, traces, screenshots, transcripts, or events prove what happened?

Sixth, operations. How will the workflow be limited, monitored, supported, rolled back, and improved?

If those answers are not visible, the next step is refinement, not sprint commitment.

The takeaway for June 5

Project Solara is a useful reminder that AI agents are becoming more than software features inside familiar apps. They are becoming part of devices, environments, identities, and operational workflows.

That makes estimation more important.

Planning poker gives teams a simple way to keep human judgement in the loop. Vote privately. Reveal the spread. Ask what data, device, permission, and recovery assumptions each person made. Record the reasoning. Then let the agent work inside boundaries the team understands.

The future of agent-first devices may be exciting, but the sprint still needs a clear story: what the agent can sense, what it can do, what humans must approve, and how the team will know when it went wrong.