We’re building Ever Works in public. Some things may be incomplete, missing, or broken while we continue improving the platform.We’re building Ever Works in public — expect a few rough edges.
For Software Companies
A software company ships a lot besides the product: documentation, a knowledge base, release notes, an engineering blog, a landing page for every launch. Ever Works runs each of them as a Work with its own repositories in your Git, so a change arrives the way your engineers already review code — on a branch, through quality gates, as a pull request your merge policy governs. And the whole platform is reachable from the MCP client they already use.
The platform half — repositories, deploys, domains, schedules, the Knowledge Base, Agents — is live for every one of these. Where the writing is still rolling out, the card says so.
A docs site or help center is a Website or Blog Work built from the knowledge you load into its Memory tab. PDF, Word, Excel, PowerPoint, CSV and HTML convert to Markdown as they arrive, every document is a Markdown file in the Work’s data repository, and a lock keeps a settled page from being rewritten by the next run.
A Blog Work: categories, RSS, code highlighting and SEO-ready content, with posts on their own tab and a cadence from hourly to monthly. Today the shared content pipeline fills the Posts tab, or you hand a post to an Agent as a Task; a dedicated blog-post generator is rolling out.
A Landing Page Work per release or campaign. Its works.yml carries the hero, the sections, the capture destination, branding, SEO and the analytics provider. The copy lives in one site config file in your repository that you edit or delegate to an Agent, while a dedicated landing-copy generator rolls out.
Nothing is generated from a blank page: a maintained template is cloned into a website repository in your Git and filled — Next.js for the Website base, Astro for Website (Minimal). The templates ship with their own tests, so the codebase you inherit is already covered.
Agents work the way your team does, and every default is the careful one. Loosen them one level at a time, once the run history gives you a reason to.
A Task gets a dedicated branch and an isolated checkout of your repository. Two Agents working on the same Work never share a working tree, and conflicts are reported by file name before a pull request exists.
Declare build, test, lint, type check or any command of your own as a quality gate on the Work or on one Task — up to 20 acceptance checks, with one to five attempts. A red check feeds its output back to the Agent; after the last attempt the Task stops instead of opening a pull request.
Merge policy decides whether an Agent may land its own pull request, set at tenant, organization, Work or Agent level, with the most specific setting winning. Out of the box, a human merges.
Ship to managed hosting on Ever Works, your own Vercel account or your own Kubernetes cluster, with a custom domain on any of them. A deploy goes straight to the live site; there is no preview-then-promote step.
The Ever Works MCP server turns the platform API into tools an assistant can call: 127 whitelisted API operations plus six Knowledge Base tools, register_work and ping, with parameters read from the API’s own OpenAPI spec so they never drift. Point Claude Desktop, Claude Code or any MCP-compatible client at it, and list Works, start a generation, deploy, set a weekly refresh or lock a brand-voice document from the conversation.
Everything an engineering team cares about — the repositories, the branches, the gates, the merge policy, the deploys — is live today. The parts still landing are the dedicated writers, and one rule about the website repository is worth knowing on day one.