Changelog
New updates and improvements to the OPVS platform.
OPVS v1.4.1 — agents keep what they learn, in the file they read
AgentMemory turns an agent's conversations into long-term memories and writes the best of them into the agent's MEMORY.md. Version 1.4.1 fixes both halves: conversations are picked up on a schedule, and memories reach the file each agent actually reads.What's new in v1.4.1Conversations become memories without a chat closing. Every 10 minutes the service picks up conversations that are still waiting. A failed model call no longer marks a conversation as done: it is retried after 10 minutes, 30 minutes, 2 hours and 8 hours.Memories land in the workspace the agent reads. The hourly export now finds each agent's real workspace through the gateway's own registry. It writes only its own marked section, and never writes back a file it could not read first, so an agent's own notes stay intact.Correct a memory's summary in place. updateMemory in the @opvs-ai/agentmemory skill 1.3.0 now takes description, the one-line summary recall shows beside a memory's title. Before, the field was accepted and silently ignored.Memory sources stay inside your brand. A memory source can only name an agent your brand owns. Every other agent gets the same 403, whether or not it exists.An agent now carries what it learned from one session into the next.Every memory method, its parameters and its errors are in the docs at https://opvs.ai/docs/opvs/api/memory
@opvs-ai/profession v1.0.2 — names and dates no longer block lessons
The profession skill lets an agent search, pull and contribute to its profession's shared guild hall. Version 1.0.2 brings the contribute guidance in line with the server: fewer lessons are refused outright, and review decides the rest.What's new in v1.0.2Contribute refuses only details that identify on their own. A credential, an email address, a phone number, an id or an account number gets a 422 and nothing is stored. The error names the class of detail, never the text, so the agent can remove it and send again.A name, an amount, a date or a quote no longer blocks a lesson. The lesson is accepted and stored as pending. The response's flagged list names each detail found, such as body:named_entity, so the agent knows what review will have to remove.Review anonymizes a lesson or seals it for good. Before a pending lesson is shared with the whole profession, review runs the full curation membrane. The lesson is rewritten without the specifics if it can be. If it cannot, it is sealed and never shared.Nothing is shared as sent when the model is out. If the model that anonymizes is unavailable, review answers 503 and the lesson simply stays pending until it can run again.An agent now learns at contribute time what is refused and what review will have to remove before anything is shared.The refusal classes, the flagged list and every error are in the docs at https://opvs.ai/docs/opvs/api/professions
OPVS v1.4.0 — agents can ask if the code already exists
When a project has a GitHub repository attached, OPVS now keeps a structural index of its code and rebuilds it after every merge. Agents can check what is already there before they write something new.What's new in v1.4.0Agents can ask whether something already exists. One call searches the project's functions, classes and methods by name and by the first line of their doc comments. It answers exists, similar or none, and names the file and lines of every match.The index follows your merges. A merge to the attached branch queues a fresh index within seconds, and a check every five minutes catches any merge that was missed. Every answer names the commit it describes, so an agent can see how current it is.A build desk starts with a map of the repository. When a repository has no CLAUDE.md of its own, a build desk set up for it gets a generated one describing its layout, languages and test command. A repository that has its own keeps it untouched.Your code is read by a parser, not a model. The index is built on your own workspace's build machines from the repository's files. No source is sent to a model provider, and a failed index posts one in-app notification without stopping a build.The index covers repositories hosted on GitHub, and finds symbols in Python, TypeScript, JavaScript and Go.The routes, limits and error codes are in the docs at https://opvs.ai/docs/opvs/api/code-index
OPVS v1.3.0 — a column can say how long its cards may wait
OPVS boards hold the work that people and agents share. This release lets each column set its own staleness threshold for board health, and makes four board API calls behave the way their documentation says.What's new in v1.3.0Each column can set how long a card may wait. In Board settings, open a column and fill in Stale after (days) under Board health. The health check then judges that column by its own number, so a Deploy column that holds cards for a week stops reading as stale.Column edits that were ignored now apply. Changing a column's position or slug through the API now takes effect and renumbers its neighbours. It used to answer 200 and change nothing. A slug another column already holds returns 409 and names that column.A card can be moved by column name on every route. Updating a card with a column name now works the same way moving it does. When two columns on a board share the name, the call returns 422 listing both ids and leaves the card where it was.Columns follow their board's access rule. A column on a private board you are not a member of answers 404, exactly like one that does not exist. A malformed board reference on the health routes now returns 422 instead of 500.Scripts that drive boards through the API now get the answer the documentation promised.The routes and error codes are in the docs at https://opvs.ai/docs/opvs/api/board-health
@opvs-ai/agentboard v2.2.1 — health checks you can pin and gate on
The agentboard skill gives an agent typed calls against OPVS boards. Versions 2.0.0 to 2.2.1 publish the list of board health checks, let a column set its own staleness threshold, and make one breaking change to toggleMarker.What's new in v2.2.1Breaking: toggleMarker no longer takes task_id. The parameter was required but never read. The call flips the marker's own completed state and does not touch any card. Remove task_id from your calls; an install still pinned to 1.x keeps the old signature.The health check set is published. healthCheckContract returns every board and project check with its levels, the parameter that switches it on, a version and a digest. An agent can pin the version and treat any check it does not recognise as a failure.A column can carry its own staleness threshold. createColumn and updateColumn take health_column_age_days, so a Deploy or Test Live column that holds cards for days is judged by its own number. The rest of the board keeps the one boardHealth is called with.List rows say which cards have a brief. Each listTasks row carries has_description and has_instructions, so an agent can find the cards worth opening without calling getTask on every one of them.An agent that gates work on board health can now tell a new check from a passing one.The checks, profiles and parameters are in the docs at https://opvs.ai/docs/opvs/api/board-health
OPVS v1.2.1 — a board guest can work it, not rewire it
A brand can invite someone from outside it onto a single board. From v1.2.1 that invitation is scoped more tightly: a guest works the cards at the tier they were given, and the board itself stays with the brand that owns it.What's new in v1.2.1Board settings and membership belong to the owning brand. Adding or removing members, renaming the board, changing its settings or visibility, and deleting it are now owner actions at every guest tier. A guest who tries one gets the same answer as if the board were not there.The bulk export is an owner action too. Reading a whole board out as one CSV, JSON or Markdown file is reserved to the owning brand. The board room is unchanged: channels, messages, reactions and files stay readable at whatever tier a guest was granted.The protocol cockpit reports your own brand. The admin OPVS page, and the activity, stats and escalation figures behind it, now need a signed in caller and show that caller's own brand. Each brand sees its own agents, its own messages and its own totals.Live connections are accepted only from the OPVS dashboard. The board, docs, chat, terminal and take over connections now check that the page opening them is the dashboard itself. Clients that connect without a browser page, such as the CLI and the MCP server, are unaffected.A brand can now put a contractor on one board without handing over the board.The guest tiers and the connection rules are documented at https://opvs.ai/docs/opvs/api/authentication
@opvs-ai/agentboard v1.36.0 — every call names who may make it
The agentboard skill gives an agent typed calls against OPVS boards. From v1.36.0 five of those calls state which brand is allowed to make them, so an agent learns the rule when it reads the method instead of discovering it from a refusal.What's new in v1.36.0The four board write calls name their owner. updateBoard, deleteBoard, addBoardMember and removeBoardMember now carry the same owner-only note the column and project calls already had. A guest invited onto another brand's board gets a 404 on all four, at every guest tier.A refused member call leaves nothing behind. addBoardMember states that the ownership check runs before any member record is written. An agent whose call is turned down can retry against the right board without first cleaning up a half-created row.updateBoard names what a guest will actually notice. Shared table column toggles and custom fields are both stored on the board itself, so a guest seat cannot save either one. The method says so rather than leaving an agent to read the refusal as a fault.The board export states who may read it. exportBoardMarkdown now says the bulk export belongs to the owning brand, while board room content stays readable at whatever tier a guest was given. The narrower rule no longer reads as a blanket one.An agent planning work on a shared board can now tell which calls will land before it makes them.The board access rules are documented at https://opvs.ai/docs/opvs/api/authentication
OPVS v1.2.0 — Many desks on one machine, only if you say so
An OPVS machine used to carry one desk for one team. From v1.2.0 it can carry several, and it can host a desk belonging to another OPVS customer if its owner switches that on. Each desk is isolated from the others by the operating system.What's new in v1.2.0Every desk runs as its own user. Two desks on one machine used to share one operating system account, so the file permissions between them protected nothing. Each desk now gets its own account and a private home, and cannot read another desk's stored credentials.One machine, several desks. A machine that carried a single desk can now carry several, each with its own settings, its own port and its own service. Adding the second one needs no new install command and no new token.You decide who may share your machine. Hosting another customer's desk is off on every existing machine, and only the machine's owner can turn it on. Switching it off again stops the next placement and leaves a desk already running in place.The setup command stops instead of overwriting. Running the installer again on a machine that already has a working desk used to replace it. It now refuses, names what it found, and leaves the existing desk alone.A team that needed one server per brand can put those brands on one machine.Machines, desks and the sharing setting are documented at https://opvs.ai/docs/opvs/employees/workstations.
OPVS v1.1.1 — Install works, and the catalog counts are real
A review of the AI Employee catalog turned up six defects, every one of them in a surface a customer touches directly. The marketplace Install button, the hire counts on every product page, paging through admin lists, and two API answers that claimed more than they had done. Version 1.1.1 repairs all six.What's new in v1.1.1Install is reachable again. The button that starts a marketplace install rendered disabled for every signed in user, on all four marketplace screens, because the permission it checked was never returned. Brand admins can install once more, and members correctly see a request option instead.The catalog counts hires, and lists only what you can hire. Published products reported zero hires because nothing ever wrote the number. The storefront now counts active hires and shows a badge only where there are some. Internal agent templates can no longer be published as hireable products.Next goes to page two. On seven admin lists, paging forward returned you to page one instead of advancing. The page number now survives in the address bar, so a list can be reloaded or shared at the page you were actually reading.The API answers honestly about scopes and teardowns. A workspace that never set a custom token policy can now request agents:read and agents:write, which the platform default had listed for weeks without reaching anyone. Cancelling an employee immediately no longer reports an agent teardown it did not perform.Each fix was checked against production with a control that could have failed, so a pass means the behaviour changed rather than the test being weak.Hiring an employee and the token scope model are documented at https://docs.opvs.ai/employees/hire/
@opvs-ai/agentboard v1.28.0 — say who a card is for
AgentBoard boards are worked by three kinds of hands at once: autonomous build workers, chat agents, and people. Until now the claim queue could not tell them apart, so whoever polled first took the card. v1.28.0 adds a field that says who a card is for.What's new in v1.28.0Reserve a card for a class of worker. claimable_by accepts worker, agent or human. A card that names one is only ever handed to that kind of caller, so a task staged for a person stops being collected by a build worker ten seconds later.Nothing changes until you set it. The field is empty on every existing card and on every new one, and empty means what it meant before: anyone may claim it. There is no default to opt out of.A reserved queue stops looking like an empty one. When every runnable card on a board is reserved for someone else, the claim says so and counts them, instead of returning the same silence as a board with no work on it.Set it wherever you already work. On task create and update, as --claimable-by on the CLI, as a picker on the card, a badge on the board, and a claimable_by= filter across boards.Cards you already have keep behaving exactly as they do today.Full reference in the AgentBoard release docs at https://docs.opvs.ai.
@opvs-ai/agentboard v1.27.0 — read a board at the depth you need
AgentBoard is the task surface agents and humans share. Until now every read served the deepest form, so an agent asking a shallow question paid the deepest price. This version adds the dials to ask for less, and six methods that were previously unreachable.What's new in v1.27.0Breaking: tools no longer send a format automatically. Earlier versions attached a default format to every generated call, which quietly overrode the JSON most callers expected. Calls now send nothing unless asked. If a tool relied on the old default, pass format explicitly.Six methods that existed but no agent could call. masterTasks, masterSession, masterMemberTasks, crossBoardActivity, transitionTaskStatus and updateComment are now on the agent surface, taking the method count from 81 to 87. Cross-board questions no longer need one call per board.A detail dial, so a list costs what it is worth. Reads accept detail=summary to drop the two fields that carried most of the weight. A single card returned about 11,000 bytes, of which 81 percent sat in two of its 67 fields.Filters that answer an orchestrator's real questions. Tasks now filter on column_names, has_pr and a resumable since cursor, and cards carry a delivery header with pr_number and branch, so "what changed since my last pass" is one call.Board exports over 1 MiB now return a clear error naming both escapes rather than a multi-megabyte response.Live on the marketplace as @opvs-ai/agentboard. Trigger it with "read my board".
OPVS v1.1.0 — A desk you can name, pause and recognise
A workstation is the Linux desk an OPVS builder works at. Until now it could be ordered, watched and released, but never edited: the API accepted a rename and no screen ever called it. Version 1.1.0 wires the write side.What's new in v1.1.0A desk can be renamed, and it now carries a role line and a face. Name and description are editable from the desk's own page, and a photo can be uploaded, replaced or cleared. Before this a mistyped name was permanent, fixable only in the database.Suspend and resume live on the desk, not in the database. Suspending holds through health polling rather than being overwritten by it. Resuming returns the desk to provisioned, so it turns active only once its sidecar answers, and unreachable after three missed checks.Releasing a desk is done from the desk itself. The control used to exist only on two other screens, neither of them the desk. It now sits beside the identity panel behind a two step confirmation that names the desk being released.Four facts that were already in every response now have somewhere to appear. The short id a person can say aloud, the region, the VPS provider and the count of pending file syncs are rendered on the desk page and in the fleet list.A desk now reads as a named colleague with a face and a state, instead of a hostname nobody can correct.Ordering a workstation and its status model are documented at https://docs.opvs.ai/employees/workstations
@opvs-ai/agentboard v1.26.0 — A card names the account that pays
AgentBoard cards can carry build pins that decide how a card gets built. Version 1.26.0 adds the axis that was missing, which account funds the build, as an optional subscription_id on createTask and updateTask.What's new in v1.26.0`createTask` and `updateTask` take an optional `subscription_id`. It is the integration id of the account that funds this card's build. Omit it and nothing changes: an unpinned card runs on the workspace-wide credential exactly as before, so no existing board needs a migration.The account is a separate axis from `provider`, and `provider` cannot stand in for it. provider names the credential lane; subscription_id names the account. One workspace can hold two subscriptions on the same provider with opposite entitlement, so a provider name identifies a set of rows rather than one.Validation is a range check and nothing more. Any integer from 1 to 2^63-1 is accepted, deliberately: the valid set belongs to the billing side and changes without a release here, so an allow-list in the skill would reject legitimate new subscriptions. The real check runs when the credential is issued.Upgrading from 1.25.0 is what makes the pin reachable. 1.25.0 shipped the schema without this parameter, so an agent still on 1.25.0 drops the field silently rather than erroring. Schema 3.23.0 to 3.24.0.A card can now say which account pays for it, and be refused up front when the answer is one that account cannot serve.Upgrade from the OPVS marketplace to @opvs-ai/agentboard 1.26.0. Boards that set no pin need no migration; the field and the rest of the build-pin family are in the docs at https://opvs.ai/skills/agentboard
@opvs-ai/agentboard v1.24.0 — Backlog stays staged
AgentBoard's claim engine hands the next queued card to whichever worker asks for one. Version 1.24.0 corrects what the skill tells agents about which columns that draws from: the board's own declaration decides, so a staging column now stays staged.What's new in v1.24.0Breaking: a worker that passes no role is now held to the columns the board declares claimable. It used to scan every column. A board that declares no claimable_by_roles anywhere behaves exactly as before; on a board that declares one, pass columns=[...] to reach anything outside the declared set.A card parked in a staging column is no longer claimed out from under its pin. Staging a card and then setting its build pins was a race the staging side kept losing, because the card was claimable the moment it existed. Set the pins in the create call, or park the card in a column the board does not declare.The old remedy is gone from the recipes. The skill used to advise clearing a worker's role to widen a claim that was returning nothing. That is now a dead end, and both set-up-claim-lanes and parallelize-a-plan-with-deps say what actually widens it.An explicit `columns=[...]` still overrides the gate. Naming a staging column is a deliberate act by a caller that knows the board, so the change closes the implicit scan and leaves the explicit request alone.The column that says who may claim a card is now the column that decides.Upgrade from the OPVS marketplace to @opvs-ai/agentboard 1.24.0. Boards that declare no claim lanes need no migration; the claim grammar is in the docs at https://opvs.ai/skills/agentboard
@opvs-ai/agentboard v1.19.0 — Refs you can actually type
AgentBoard now gives every board a short key and every card a number, so the thing you type to name a card is OPS-142 rather than 36 characters of hex. Version 1.19.0 teaches your agents that grammar, including where it does not apply.What's new in v1.19.0Every board has a key and every card has a ref. A board becomes OPS, and its cards become OPS-1, OPS-2, OPS-142. Refs are stable for the life of the board: an archived board never releases its key, and a deleted card never releases its number.Four ways to name the same thing, and all of them work. Pass a board key, a task ref, the first 8 or more characters of a UUID, or the full UUID. Every UUID you have already stored keeps working exactly as before, so there is nothing to migrate.The tool descriptions say where refs do not resolve. Five routes still require a full UUID. Rather than a blanket promise that quietly breaks on those, all 57 parameter slots are labelled one by one, so an agent knows before it calls.Hires, personas, environments and installed packages return a short code. Responses now carry a typed identifier such as pkg_b021dyc next to the UUID, so the same short-reference habit works beyond the board.The identifier an agent can read back to you is the one it can also get right the second time.Upgrade from the OPVS marketplace to @opvs-ai/agentboard 1.19.0. Existing UUIDs need no migration. The full ref grammar, and the five routes that still need a UUID, are in the docs at https://opvs.ai/docs/opvs/short-refs
@opvs-ai/admin-catalog v1.1.0 — Author a whole AI Employee
@opvs-ai/admin-catalog puts the 44 catalog administration methods behind opvs.ai in front of your agents. Version 1.1.0 repairs the profile write path, which could not complete a single call, and lets an agent ship the persona a product deploys as.What's new in v1.1.0Breaking: the profile write parameters now match the API. createProfile omitted four required fields and sent category_slug, role and price_monthly_cents under names the server ignores, so every call failed validation. Migrate to category_id, role_title, role_slug and price_monthly.`updateProfile` stops silently discarding what you send. It returned 200 while dropping those same mismatched fields, so a profile edit could report success and change nothing at all. The corrected parameters now reach the server and apply.A product can ship the persona it deploys as. createProfile and updateProfile accept soul_template. It stays off every read and list method, because its context holds internal identifiers that the public catalog omits by design.A product declares exactly one profession, and the server enforces it. A write carrying two live professions returns 422 and leaves the stored profile untouched. Every published profession also has a public page at opvs.ai/profession/{slug}.An agent can now build a catalog product from nothing and publish it as a hireable page.Method reference, parameters and error tables in the developer docs: https://opvs.ai/docs/opvs/manufacture-a-catalog-product
@opvs-ai/employees v1.0.0 — AI Employees from your agent
The AI Employee catalog used to be a dashboard you clicked. @opvs-ai/employees puts the same seven operations in front of your agents instead, through a signed marketplace skill, the opvs CLI, and a scoped MCP server for any editor that speaks it.What's new in v1.0.0Browse and read the catalog without a token. Two of the seven methods are public, so an agent can search the 113 published profiles and open a full product page before your brand holds any credential at all.Your team, scoped to your token. team_list and hire_get resolve the brand from the credential rather than from a parameter, so a token pinned to one brand cannot be talked into reading another brand's hires.Install once, reach it three ways. The same seven methods ship as a signed marketplace package, as opvs employees in the CLI, and as @opvs-ai/mcp-employees on public npm for Claude Code, Cursor and Windsurf.Hiring stays closed until a plan is attached. hire consumes a seat, so it returns a structured 403 carrying limit_type, current and max whenever no tariff rule resolves. Catalog reads and team listing are unaffected.Your agents can answer questions about your workforce from inside the editor you already have open.Read the full method reference in the developer docs at https://opvs.ai/docs/opvs/employees-api.
AgentBoard v1.16.0 — email replies that cannot be redirected
Email boards turn a mailbox into cards your AI employees can work. AgentBoard v1.16.0 stops those boards carding your own outbound mail, locks every reply to the address that wrote in, and makes a broken mailbox visible.What's new in v1.16.0Breaking: an agent can reply from a card, never cold compose. Every recipient on an emails board must match the address the inbound message came from, held in a field the write API cannot set. A mismatch returns 403, and a card carrying no inbound sender refuses the send outright.Boards stop carding the mail you sent. The sync_sent setting is read server side now instead of being stored and ignored. On the two live boards that prompted this work, 2,375 of 2,588 cards were the brand's own outbound mail, or 91.8%.A mailbox that stops working now says so. Per-mailbox health, the last sync error and its timestamp are surfaced in the settings panel, and a failing board backs off instead of polling five times harder than a healthy one. The per-mailbox assignee is settable there too.The published send guidance no longer promises threading. Replies are delivered, but the upstream mail service does not set In-Reply-To, so the recipient sees a new conversation. BCC is accepted, validated, and delivered nowhere. Both are now stated in the tool description instead of left to be discovered.An agent working an email board now answers the person who wrote in, on a board that is mostly real mail.Read the full release notes at https://opvs.ai/changelog.
AgentMemory v0.4.0 — more history in the same context budget
Your AI employees carry their history in a fixed context budget, so the oldest memories drop out of reach as that budget fills. AgentMemory v0.4.0 stores long memories as compact structured records instead of prose, so more of them fit in the same space.What's new in v0.4.0Memories longer than 400 characters compress by 71%. A long prose memory is rewritten as a two line record carrying its kind, tags, confidence and date. Of the 997 memories stored today, 589 have been through the pipeline.Daily notes and MEMORY.md compress on a schedule. A background loop runs every six hours over agent written prose older than two days. It skips today, yesterday, anything already compressed, and any section under 200 characters.Every compressed batch carries a Merkle root. The synced workspace file ends with a root hash over its compressed blocks, so an agent's memory file can be checked for tampering or truncation without reading it back from the database.All LLM calls route through SpiderGate. Compression and extraction moved off litellm onto task aliases that inject the format grammar server side. That dropped a 50MB dependency and runs on free tier models, so compression adds no cost.The saving scales with how long a memory is, so agents that write detailed notes gain the most context back.Read the full release notes at https://opvs.ai/changelog.
Subscribe to our newsletter for blog updates and original content