Maya changelog

• New tasks and goals now only offer agents that can actually run, and agent/squad empty states include company-operations templates.

Highlights

• Agent and squad empty states now include operations templates such as executive assistant, project manager, analyst, operator, coder, and reviewer.
• Task creation, goal planning, and agent handoff only show agents with an online execution assistant.
• Unavailable-agent errors now explain the next action: connect or enable the execution assistant, or pick another online agent.
• Task copy, goal copy, and agent handoff preserve context snapshots without rewriting previous execution history.

• While an agent is queued or a long task is still running, the task detail and Worker queue card now show your queue position and the latest progress.

Highlights

• Task detail adds an "Agent queue / Queued #N of M" panel so you know exactly where you stand in line.
• Long-running tasks now show their current stage and percentage, such as "Agent is reading the codebase — 60% done".
• The Worker queue card exposes the same queue position and progress summary, no need to keep refreshing the list.
• High-risk tasks show a minimal safety brief before queueing, listing the resources they will touch and what happens if you decline.

• The artifact readout on a goal is now a button that opens a drawer, grouped by the source task that produced each artifact.

Highlights

• The drawer only fetches artifacts after you open it, so opening a goal stays cheap.
• Final artifacts are grouped by task, so you can immediately see which task produced what.
• Each artifact only shows the actions it actually supports (preview, download, open local, view task) — disabled actions stay hidden.
• Intermediate artifacts and superseded copies never show up in the drawer, so what you see is always the final deliverable.

• The Maya workbench tab title and favicon display the current unread Inbox count, so you can spot new messages even from another tab.

Highlights

• When unread is 0, the tab stays a clean "Maya" — no persistent visual noise.
• Unread count shares the same deduplication logic as the in-app Inbox badge, so the same message never counts twice.
• The signal is scoped to logged-in workbench pages; landing and login pages stay quiet.
• On logout or returning to zero unread, the title and favicon automatically restore.

• High-density task detail stays readable: long comments collapse by default, and a dedicated note shortcut is never mistaken for an agent task.

Highlights

• Typing `/note content` in a comment is recognised as a task note and saved as a regular comment, never dispatched to an agent.
• Long comments enter task detail collapsed to an 80-character preview, and stay expanded for the rest of the session after you open them.
• Task list and Workbench home keep using the same combined filters and swimlanes — the density baseline is unchanged.
• The sidebar help menu stays split: docs for tutorials, changelog for changes, feedback as an action entry.

• The workbench now leads with Project > Goal > Task. Entering a project or goal uses the same task list, filtered by the current context.

Highlights

• The workbench starts from projects first, then goals and tasks, matching how work is usually organized.
• Project detail no longer adds a separate outline; all project tasks and standalone tasks stay in the shared task list.
• Goal detail also uses the same task list and shows only tasks linked to the current goal.
• Project, goal, and task explanations moved into question-mark help popovers, keeping pages quieter without hiding help.

• Docs and changelog now stay inside the workbench instead of throwing users into a mixed page or an external site.

Highlights

• The help menu now routes separately to docs and changelog.
• Feedback stays as an action instead of pretending to be a third content page.

• The docs page now teaches three user paths: connect a local assistant, start a goal, and start a task.

Highlights

• The copy now reads like instructions a project manager or operator can follow directly.
• The layout switched from long text blocks to tutorial cards.

• When a project working directory is bound, final files land more reliably in the project root instead of disappearing inside run folders.

Highlights

• Task artifacts remain the formal delivery entry.
• The project root also becomes easier to use as the visible handoff location.

• Home, goal list, and goal detail now share the same unread, risk, and blocker logic.

Highlights

• Completed historical dependencies no longer keep a goal marked at risk.
• Old messages on the same task no longer inflate unread counts.

• The admin console adds read-only visibility into users, workspaces, tasks, and pending invitations.

Highlights

• The first version is read-only to avoid risky management actions.
• Admin access is controlled by an email allowlist for small-team operation.

• Workspaces can create invitations, copy links, send email, and let invited members accept or decline.

Highlights

• Invitations start as pending records that admins can review or revoke.
• When email is not configured, admins can still copy and send the invite link manually.

• The local assistant becomes a user-facing execution environment with clearer online state, machine ownership, and setup steps.

Highlights

• Local assistants handle private files, internal networks, and local tools instead of mixing with cloud execution.
• The product starts teaching users to connect a local assistant before work that depends on local material.

• Projects can bind a local working directory so tasks keep advancing around the same files and materials.

Highlights

• Goals inherit project resources instead of storing local paths directly.
• Run folders and final delivery folders are separated to keep process files out of user folders.

• Follow-up instructions on a task start reusing the working directory, artifact summary, and execution context.

Highlights

• Users do not need to re-explain what files were generated last time.
• Later tasks can continue from an existing Markdown, DOCX, or research result.

• Maya starts treating Markdown, DOCX, slides, and spreadsheets as managed artifacts instead of leaving results only in chat.

Highlights

• Task detail pages can show and download final outputs directly.
• Execution summaries and process logs begin separating from user-facing delivery.

• Human decisions become approvals inside the task flow instead of waiting in chat for someone to remember them.

Highlights

• Approval copy must explain who asked, what will happen, and what happens if it is not approved.
• High-risk tasks can pause before execution until the user confirms.

• After users write daily work notes, Maya can split them into queued, dependent, and trackable tasks.

Highlights

• Status, owner, dependencies, and execution records become core task information.
• Code, copywriting, research, and deck/material work can share the same queue.

• A Goal becomes the place where Planner Agent splits tasks, orders dependencies, and defines deliverables.

Highlights

• Users write the result; Maya turns it into next steps.
• Complex work can be reviewed as a plan before different agents execute it.

• The direction shifts from asking a chat box to writing today’s work priorities like a work calendar.

Highlights

• Users only need to write priorities, source material, and deadlines.
• Agent calls are hidden behind planning, queueing, execution, and artifact return.

• Maya starts feeling like a shared workbench with multi-workspace support, notifications, timeline activity, and board cleanup.

Highlights

• Multi-workspace daemon support and a stronger notification model arrive.
• Boards and activity timelines move closer to everyday usability.

• Multi-workspace handling, agent management, comments, and the event bus enter the main product line.

Highlights

• Agent management, inbox, and CLI management become real product surfaces.
• Comments and WebSocket updates complete the first collaboration loop.

• The backend, frontend, real-time layer, and test base come together into the first working platform.

Highlights

• REST API, JWT auth, and real-time WebSocket land together.
• Board, list, agents, inbox, and settings get their first usable versions.

• Maya formally separates the control plane from the execution plane, with cloud by default and local assistants for private capability.

Highlights

• The API server stays in the control plane while Runtime / Worker handles execution.
• Local assistants are positioned for private files, internal networks, and sensitive tools.

• The workbench information architecture starts to take shape and chat stops being the only center of gravity.

Highlights

• The first UI sketches for Goal, Task, Approval, and Artifact appear.
• Navigation, task queue, detail timeline, and artifact area become the base structure.

• Maya is defined as a daily workflow platform where users write work notes and agents break down and complete the work in the background.

Highlights

• Multi-agent collaboration, queues, human confirmation, and reusable outputs become the first product spine.
• The scope goes beyond code into copywriting, research, materials, reports, and course development.

• Maya starts from the vision that calling agents should feel as simple as writing a daily work calendar: write today’s priorities, then let the system split and advance the tasks.

Highlights

• The first principle is that users should not need to choose which agent to call; they should write the goal, material, and timing.
• Maya is meant for everyday work beyond code, including copywriting, research, materials, reports, course development, and operations reviews.