What shipped in Ever Works

Schedules has its own entry in the sidebar, above Runs and Activity. It lists recurring Tasks, Agent heartbeats, Work schedules, Mission ticks, source validation, data sync and inbound triggers. Each row shows the Agent that runs it, the cadence with a countdown to the next run, and its status. Filter by Agent, source, status and health, or search.

• Pause keeps the cadence. Pausing a recurring Task no longer deletes its schedule, and pausing a heartbeat no longer pauses the whole Agent. Resume continues at the next future slot, without a burst of catch-up runs.
• Run now starts one run without changing the schedule.
• NEVER RUNS flags a cadence that can never fire, such as a date that does not exist, an end date in the past or a recurring Task with no Agent, and previews a suggested repair.

Pausing a Mission pauses the whole Mission, so it asks you to confirm. Work schedules, source validation and data sync stay managed in the Work's own settings.

Limits: applying a suggested repair, a calendar view and bulk actions are not available yet.

Open Settings → Notifications, or use the link at the bottom of the notification bell. Events are grouped as Needs you, Signals, Routine and Digest, with one switch per delivery target and no Save button.

• Email goes to your account's address, with nothing to connect. By default, the events only you can unblock (agent questions, approvals and escalations, a blocked Mission, an expired Git sign-in, credits and billing stops) also send an email.
• In-app off means "don't interrupt me": the notification is still recorded but stays out of the bell's unread count.
• Turning every switch off for an event now sticks instead of falling back to the defaults. Reset to recommended restores them.
• Quiet hours still hold deliveries back, and you can choose to let urgent events through.

Nothing changes until you change it: every event keeps reaching the bell as before. Budget alert emails still follow the setting on your profile.

A Facts section now sits at the top of Memory. Use Add a fact to type one (up to 500 characters), or ask the chat assistant to remember something and it saves the fact for you.

• Search matches by meaning when an AI provider and a vector store are available, and by exact words otherwise. The page tells you which.
• Edit, pin, forget and restore each fact. Forgetting one offers Undo for ten seconds, and a forgotten fact stays restorable for 30 days.
• Forget all clears every fact after you type FORGET ALL to confirm. It never touches documents or files.

Limits: this first phase stores and manages facts only. Agents do not receive them in their runs yet, pinned facts included; that comes in a later release. A workspace holds up to 2,000 active facts.

Open the command palette (Ctrl+K or Cmd+K) and choose Catalog. There is no sidebar entry yet.

• Playbooks are packaged outcomes. Each one lists its trigger, steps, the capabilities it needs, what it produces and when it stops to ask you. Eight built-in Playbooks ship, and five of them need no connection. A readiness label says whether your enabled plugins cover what a Playbook needs, with a Connect link to Plugins when they don't.
• Search (press /) and the category and readiness filters narrow every section at once.
• Saved Workflows get their own list and detail screens: run one, reactivate an archived one, and open its run history and full trace.

Limits: the catalogue is read-only. A Playbook's main action takes you to create the Agent yourself; setting a Playbook up in one step comes later.

Press ?, use the Help control in the top bar, or choose Help & Docs from the sidebar menu. The Manual tab shows:

• On this screen: the articles that explain the page you are on.
• Six sections to browse, and instant search over titles, summaries and headings.
• An article reader with its own contents list, related articles and a button that opens the screen it describes.

Every article and heading has its own address under /help, so you can send a teammate straight to the right section (they need to be signed in). How this works links on empty screens (Missions, Ideas, Tasks, Agents, Works, Skills, Teams, Memory, the Knowledge Base and Schedules) and Why am I seeing this? on Home attention items open the right article in place.

Articles come from the same pages as docs.ever.works and match the version you are running. The Tips, Shortcuts, FAQ and Resources tabs are unchanged.

The step comes right after you tell setup what you do and how big your team is. It proposes:

• A coordinator to hand work to when you are not sure who should own it. It delegates to the right specialist and raises an escalation instead of guessing.
• One specialist per lane, such as Research, Content, Outreach, Search visibility, Social or Market watch, matched to your roles.

Rename any Agent, drop what you don't need, add what is missing, then press Create my agents. The Agents are created in the background while each lane shows its status: created, reused, not enough seats, or failed with a reason. Running it again only fills the lanes that are still empty.

Every Agent it creates is active, asks for review before acting and has no schedule of its own, so it only works when given work. Specialists report to the coordinator. Skipping the step creates nothing.

Open the Skills section of the Agents page. A ready Skill shows no badge. Otherwise the card says why it cannot reach a run: Not reaching any agent, Missing N requirements, Blocked by your access rules, Switched off or Couldn't check.

• Missing items are named, for example a connection that is not connected or a credential that is not set (never its value), with a link to Settings → Connections or the Agent's capabilities.
• Re-check runs the check again in place, and an hourly sweep refreshes old results.
• The on/off switch turns a Skill off for the whole workspace from the next run, without touching its bindings.
• Filter by tags, state and search. The summary line, such as "6 of 34 Skills need you.", shows only those Skills in one click.

A Skill's detail page adds Readiness, Requirements and Where it came from panels above its existing sections.

A Task could already list an Agent as an approver, but that Agent never reviewed anything. Now, when the Task enters In Review, and again when its pull request gets new commits, each pending Agent approver gets its own review run.

• The run sees the full diff and the CI verdict, and can only record a verdict. It cannot edit files, push or move the Task.
• An Agent cannot approve its own work. An approver that worked on the Task is refused.
• Your merge approval still applies. An Agent's approval never stands in for a person approving the merge.
• Cost is capped, by default at 4 review runs per Task and 2 Agent approvers per review.

Limits: approvers are added through the API, the MCP server or the chat assistant, since no screen creates them yet. Reviews are not available yet for Tasks that run on your own fleet nodes. A diff that is too large or incomplete is not reviewed, and the approval stays with a person.

Press Ctrl+K (Windows and Linux) or Cmd+K (Mac), or click Search… in the top bar. / also opens it when you are not typing in a field.

• Search your workspace. Type two or more characters to find Missions, Tasks, Agents, Works, Ideas, Skills, Teams and Knowledge Base documents in the active workspace, grouped by type.
• Go to any screen, including every Settings page and the pages of the Work you have open.
• Run a command: create a Mission, Task, Agent, Goal or Meeting, switch workspace or Work, open the AI chat, copy a link to the page, toggle dark mode or sign out.
• Move fast. Tab narrows the list to one group, Ctrl/Cmd+Enter opens a result in a new tab, and your recent items show while the box is empty.

If nothing matches, the palette offers to ask the AI chat or to create a Task from what you typed. Inside a Work's Knowledge Base, Ctrl/Cmd+K still opens that workbench's own search, and the top bar button opens this palette.

Limits: runs, decisions, Memory, Goals and Meetings are not searchable yet, and recent items are remembered per browser, not across devices.

Open an Agent and choose the new Inbox tab. The Sending policy panel has two parts.

• Approval. Draft for review keeps everything the Agent writes as a draft until a person approves it. Auto-send lets it send on its own. Waiting drafts show in the Agent's Inbox with Approve & send and Discard, and in your approvals queue. A draft is sent once, and approving in bulk never sends email.
• Send limits. Set sends per 24 hours, sends per minute, recipients per 5 minutes and recipients per message. Leave a field blank to inherit it, or enter 0 for no limit. Apply recommended limits fills them in one step, and a live meter shows usage against each limit.

Limits are checked at the moment of sending, whether the Agent, another Agent or a person wrote the message. A message over a limit is not sent: a draft stays a draft, and you are told which limit was reached and when capacity returns. The same tab lists the Agent's messages and lets you choose which of your addresses it sends from and receives at.

Limits: an Agent you have not configured keeps sending as before, with no limits. Adding a new email address is not in the product yet; that step still goes through the API.

Look for What's new in the top bar, next to the notification bell. A badge shows how many updates you have not read.

• Read in a side panel. Updates are listed newest first, with any pinned update at the top, each marked New, Improved, Fixed or Security. Some include a button that takes you to the screen they describe.
• Filter by area: Agents & Missions, Decisions & Safety, Knowledge & Memory, Connections & Computers, Runs & Costs, or Platform.
• Your own read state. An update counts as read once it has been on screen for about a second, or use Mark all as read. It is tracked per person, so switching workspace does not change it, and a new account starts with nothing unread.

The updates you see are the ones that shipped with the version of Ever Works you are running, and the panel never opens by itself.

Limits: the panel holds a short list of selected updates, not the full changelog, and the badge count refreshes on your next page load.

Open Tasks and choose Kanban (/tasks?view=board).

• True column totals. Each header counts every Task in that status under your filters, not only the cards loaded on the page. Show N more loads the next cards of that one column.
• Urgent work first. Stalled Tasks in progress come first, then priority P0 to P4, then the oldest update. Use Sort to switch back to Recently updated.
• Choose how far back completed work goes. Completed shows Done and Cancelled Tasks from the last 7, 30 or 90 days, or all time.
• Linkable. The view, sort and completed window stay in the link, the page remembers the view you used last, and applying a filter keeps you on the board.

If the platform refuses a move, the card goes back to its column and the reason is shown. Dragging a cancelled Task explains that it cannot be reopened.

Limits: Cards is still the view you land on by default, and a stalled Task is not flagged on its card yet.

Connection health. Open Settings → Connections. Each MCP server now shows Healthy, Having trouble, Expired, Unreachable or Not checked yet, based on its last real connection: a run using its tools, a tool call or Test. Credential problems come with a one-line fix, and a banner counts the connections that need attention.

Access levels. Open an Agent, go to Capabilities → Access levels, and choose Read only or Read and write for a provider. Read only lets the Agent look things up but never change anything. For GitHub, Read and write adds committing to a repository and opening pull requests. The change applies on the Agent's next tool call. If a broader setting narrows the level, the section says so, and a level the connected account does not permit asks you to reconnect.

Credentials only over https. Saving a connection that carries an auth header now needs an https address, so the header is never sent in the clear. One saved earlier on plain http is marked Unencrypted and is refused the next time it tries to connect.

Limits: GitHub is the only provider with access levels so far. Health updates only when something connects, with no background check yet.

Every commit a fleet run made used to carry the same generic Ever Works Agent identity, so your Git history could not tell you which Agent or which machine produced a change. Commits from runs on your own machines now say who did the work:

• Author: the Agent, by name, with an @agents.ever.works address unless the Agent has its own committer email.
• Committer: the machine, as Ever Works node <node name>.
• Trailers: the commit message ends with Ever-Works-Node, Ever-Works-Agent, Ever-Works-Job and Ever-Works-Run lines, so you can trace a change back to its run.

These values come from Ever Works records rather than from the Task text, and a node refuses attribution that names a different machine.

Limits: this applies to runs on fleet nodes, not to runs in the cloud. The Ever-Works- trailer namespace is reserved, so a run fails if its commit message already carries a line that looks like one of these trailers — a Task title can reach the message. Rename the Task if that happens.

Some outcomes are not a number: "ship feature X across three repositories" or "migrate the docs site". A delivery Goal covers them.

1. Open Goals and create a new Goal. Set Goal kind to Delivery, and the metric source and target fields disappear.
2. Enter the Definition of Done, one criterion per line. At least one is required, and every line you enter starts approved.
3. Activate the Goal. The execution loop hands iterations to agents as usual.

The Goal completes as achieved when every approved criterion is done or waived. Criteria an agent proposes do not count until you approve them, so an agent cannot finish a Goal by declaring it finished. A deadline still applies, and a passed deadline ends the Goal as missed.

A brand-new Goal also no longer stalls for want of an agent: if none is pinned and none has worked on it yet, it picks from the eligible agents in the Goal's own scope.

Limits: the kind is fixed once the Goal exists, and the checklist can be edited but never emptied. Existing Goals stay metric Goals.

Cost and tokens. When a run executes on one of your machines, Ever Works now records its token counts and, when the CLI prices the run, its cost, so budgets, Goal spend and cost views include it. The figure is the CLI's own estimate, billed to the account that machine's CLI is signed in to, never to platform credits. Codex reports tokens but no price.

Daily cost ceilings. On Settings → Fleet, set a Daily cost ceiling for the whole fleet, or open a machine's details to set one for that machine. Days are counted in UTC. Crossing a ceiling drains the affected machines and files one Inbox notice. Drained machines stay disabled until you re-enable them, so raise the ceiling first if the spend was expected. A machine ceiling on a CLI that reports no price drains that machine on its first finished run.

Panic controls. Drain all nodes disables every enrolled machine and returns their jobs to the queue without cancelling anything. Cancel in-flight work is a separate step that aborts running jobs and their agent runs, optionally including queued ones. A banner on the page tells you when the platform-wide stop is on; that stop is set by the platform operator.

Concurrent iterations. A Goal still runs one iteration at a time by default. On the Goal page, open Adjust limits and set Concurrent iterations (1 to 10) to let the loop start several at once, each as its own Task and agent run. Every iteration passes the same checks as a single run, including budgets, credits and concurrency limits, so a higher number asks for more parallelism without adding capacity.

Raise it only for Goals whose iterations are independent. Nothing keeps their workspaces apart, so iterations editing the same repository on the same branch will overwrite each other.

Template steps across repositories. A step in a workflow template can now name its own Work and extra repositories, so one template can say "write the spec in the platform, update the docs site, publish the announcement". Create the Task tree as before from Tasks, new Task, From template. Each step's Work and repositories are checked against you when the template is saved and again when it is used, and a step you can no longer reach stops the whole tree instead of filing work in the wrong place.

Limits: creating and editing workflow templates is API-only for now.

A machine that had stopped itself used to look online and idle while refusing every job. Now:

• Worker state in the machine's details. On Settings → Fleet, open a machine to see Idle, Working, Paused, Quarantined or Throttled, with the reason and since when. A machine that has never reported shows Unknown, not idle, and its job history shows each run's real outcome.
• Inbox notices. You get one notice when a machine goes offline, another if it stays offline (30 minutes by default), and one when it quarantines itself. Each resets when the machine recovers.
• Routing to machines that can take the job. Only machines that match the Agent's pinned machine and the capabilities the job needs count as free. If none can take it, your execution routing rule applies: by default the work runs in the cloud and you are told why, or, if you chose to wait for your own machines, it stays queued and starts once a matching machine is back online.
• No job waits forever. An agent job no machine picks up within 24 hours fails with a Fleet run never started notice.

Limit: offline notices are checked while a dashboard page is open or when work is dispatched, so with nothing open you see them on your next visit.

Sleep-safe runs. Desk machines sleep. Before, a sleeping machine's job could be handed to another machine while the first model run was still going, and one of the two runs on the same branch was wasted. Now the node notices when it wakes, stops any run whose claim lapsed while it slept, pushes nothing and reports the failure, and the job carries on elsewhere.

Disk floor. A machine refuses new work while its workspace volume has less than 2 GiB free, or when free space cannot be measured, and shows as Throttled. A job refused for disk goes back for another machine instead of failing. Change the floor with --min-free-disk, or switch it off with --no-disk-floor.

Workspace cleanup. With --work, the node removes Task workspaces older than 14 days (--workspace-max-age) only when it can prove they are safe: not in use, no uncommitted changes, fully pushed, and the branch merged or gone. ever-works-node doctor shows what it would do, and ever-works-node gc --dry-run previews a sweep. A machine's details show Disk & workspaces: above or below the floor, workspaces kept and the last cleanup.

Action needed: update the node app on every machine. Node builds from before this release cannot keep or finish jobs.

Env files on your machines. Store a repository's .env files under Settings → Repositories. When a run on one of your machines needs them, the node fetches them only while it holds that job, writes them readable by the owner only, keeps them out of Git, and deletes them before the run's first Git command and again when the run ends. The job records which files are needed, never their contents, and the values are scrubbed from what the node reports back. If a file can no longer be resolved, the run fails instead of starting with half an environment.

Env grants (API only). You can also let runs read specific variables that are already set on the machine, by exact name. Agent-driven code can then read those values, so grant as few as possible.

Repository-declared setup and checks. A repository can list tasks.setup and tasks.checks commands in .works/works.yml, including checks for another repository mounted in the same Task. Setup runs before the agent, and a failed setup is reported as a setup problem, not as a failing test. Nothing runs unless each command exactly matches the Work's allow-list, which is set through the API for now.

Real changes often cross repositories: an API field in one, the screen that uses it in another. A Task still has one main Work and branch, and it can now bring more repositories along.

• Choose them. Attach repositories to the agent under Capabilities → Repositories, or tick them under Also work in on the new Task form or the Task page. Both lists come from Settings → Repositories. A Task's choice wins over the agent's for the same repository.
• The run sees them. The machine checks each one out at .mounts/<name> inside the main checkout, on the same Task branch name, and tells the model where each one is.
• Review them. Every repository that changed is pushed and gets its own pull request, linked to the main one. The Task's branch panel lists them under Also in, and one Inbox notice links every pull request.

Limits: this applies to runs on your own machines in model-cli mode, not to cloud runs. A Task can bring at most 8 extra repositories, and acceptance checks run in the main repository only. A repository with no GitHub connection behind it is pushed but gets no pull request. If Ever Works cannot read a repository's details, the run fails naming it instead of running without it.

An agent running on your own machine cannot message you mid-run. It can now park the run with a question instead of guessing.

• The question reaches your Inbox, tagged From your fleet, with the machine, the Task, the branch and a link to any pull request. The Task page shows that the run is waiting and links to the question.
• Partial work is kept. What the agent did so far is pushed on the Task branch when its git policy allows it, but no pull request is opened and the Task does not move to In review.
• Replying starts a new run for the same Task, with the same agent, pinned machine and branch. Your question and answer are part of its instructions.
• Archiving the question stops the parked run from waiting.

Limits: this is for runs in model-cli mode on your own machines. One question per run, answered in free text with no option buttons. An agent in the plan permission mode cannot ask. A reply to a Task that is already Done or Cancelled does not start a run.

Pinning an agent to a machine used to need the API. Now open the agent, go to Capabilities → Execution and choose a Preferred node.

• Pinned work waits for its machine. With a node chosen, only that machine takes the agent's jobs. If it is offline or drained, the jobs wait instead of failing, and the picker tells you so.
• Any node, the default, lets whichever of your machines is free take the work.
• Removed machines stay visible. If the pinned machine was removed from your fleet, the picker still shows the pin so you can clear it or choose another machine.
• Routing at a glance. The section shows your account's execution routing rule, read-only, with a link to change it in Settings → Fleet.

Job history per machine. On Settings → Fleet, a machine's details now list every job, not only failures: kind, status, attempts, queued, started and finished times, duration and why a job is still waiting. Filter by All, Failed or Running.

Limits: pinning is for Organization agents; in a personal workspace the section explains this instead. A new pin applies to future jobs only.