--- name: era description: What Era is and how to work with it: build a synthetic company with the era CLI (era init, era new), get its internal systems as MCP servers and REST APIs (era mcp --client claude), and read one story across all of them. --- # Era: a synthetic company's internal systems, opened to your agent `era new` provisions a synthetic company and hands you the systems it runs on - Salesforce, HubSpot, Zendesk, Jira/Confluence, Gong, Slack, Google Drive and the file stores - each as its own MCP server and REST API, in the vendor's own schema, query language and auth shape. What you get is not a dataset to load: it is the company's stack, queried the way you would query the real products. Every environment is 100% synthetic: no real records, no real people. The data plane is read-only, so the company does not change under the agent working in it. ## One company, seen from every system The systems are views of a single company, not separate fixtures, and that is the point of working here: - **The same entity appears wherever it belongs, in each system's own terms.** An account is a Salesforce `Account`, a HubSpot company and a Zendesk organization; the person on it is a contact, a ticket requester, a Slack member and a voice on a Gong call. Every system keeps its own ids, so you join the way you would in a real company - on names, domains, emails and timing - not on a shared key. - **One thing that happened leaves traces in several systems.** A deal going sideways is the opportunity's stage and slipping close date, the Gong call where the objection was raised, the Slack thread where the AE asked for a discount, the Zendesk ticket that made the customer nervous, the Jira issue behind it and the Drive doc that got rewritten. No single system holds the whole account of it. - **The timeline spreads and develops.** Records arrive in the order a company would produce them - calls before the opportunity, the ticket before the escalation, the bug before the runbook edit - and a thread widens over weeks: one ticket becomes a bug, becomes a policy change, becomes a renewal risk noted months later. "What changed, and when did we first know" is answerable. So the questions worth asking are cross-system: why an account churned, which bug is costing revenue, what a rep should know before the call. Any one system answers them only partly, on purpose. ## Build one ```sh era init # browser sign-in; the keys stay on this machine era new --industry fintech --size mid \ --systems salesforce,zendesk,slack # `era options` and `era systems` name the values ``` `era new` writes a marked block into `.env`: `ERA_CONSOLE_URL`, `ERA_TENANT`, `ERA_TENANT_TOKEN`, and a `_BASE_URL`, `_MCP_URL` and `_MCP_HEADER` per system. `era ls` lists the companies the account holds; `era ls ` describes one. ## Point Claude at it ```sh era mcp --client claude # one `claude mcp add` line per system, credential included ``` Register every system. Keep the `-` server names the command prints: one machine holds several companies, and a client with a global `slack` answers from whichever was registered last. One token opens the whole stack; it is the tenant's token, not the CLI's console credential. ## Work in it - Ask each server what it exposes (`tools/list`) instead of guessing: the tools are named for the vendor's own operations (`run_soql_query`, `slack_search_messages`, `search_tickets`, `search_files`). - Resolve the entity in one system first, then follow it outward: carry its name, domain and the emails of its people into the next system, and search a time window rather than an id. Expect each system to call it something else. - Build the timeline before concluding. Put what every system returned on one axis by timestamp, and read the order: what came first, what it turned into, where the story stops. A conclusion that rests on one system's records is usually the wrong one here. - Answer with `system:id` attribution - a Salesforce id, a Slack channel and ts, a Zendesk ticket number. If a system returned nothing, say so rather than inferring it from another. - Answer the question that was asked, then stop. Lead with the finding, put the evidence under it, and leave out what was not asked for: no preamble, no restatement of the question, no summary of the work, no extra sections. Report the part of the investigation the question needs, not everything it turned up. - Writes are refused (`403 writes_disabled`), so an evaluation scores every run against the same company. Advancing an environment a quarter regenerates it from its recipe; ids and anything a client wrote are the recipe's again. - The same systems answer plain HTTP at `_BASE_URL` with the same token, in each vendor's own auth shape, when the agent is code rather than a client. Machine-readable facts and limits are at `/llms.txt`; the reference is `/docs.html`.