Era generates simulated companies for agent testing

• Era generates a synthetic company across Salesforce, Zendesk, Jira, Slack, Gong, and other systems, then exposes it through vendor-compatible MCP and REST interfaces, according to rohanpaul_ai's report.
• The records share one underlying company graph, so the same customer, employee, deal, ticket, and call can be followed across systems, as omarsar0's breakdown describes.
• Teams can reset the company, swap a model or prompt, and rerun identical tasks against known state instead of rebuilding an environment for every test, rohanpaul_ai's report says.
• Evals become experiments over the model, harness, tools, prompt, and infrastructure in Vtrivedy10's simulation-machine diagram, with production trajectories feeding the loop.

The architecture page describes a seeded graph projected into each vendor schema, while Eon’s launch post spells out the MCP servers and simulated APIs. Era’s docs expose the environment through a CLI rather than treating it as a static dataset.

Mocks, narrow synthetic datasets, and production each hide a different failure mode, according to rohanpaul_ai's report. Levie described the current enterprise pattern as testing and tuning real-work environments one company at a time, with eval infrastructure and simulated environments becoming a separate operational need.

Eon introduced Era as a free environment for model comparison, post-training, workflow development, integration testing, and demos, according to the launch post.

Era asks for an industry, company size, and systems, then projects one generated business into the selected connectors. The result is designed to preserve relationships that ordinary row-level mocks lose.

• Shared identity: the same customer, employee, deal, ticket, conversation, and call can appear across systems because the records come from one company graph, according to Era’s architecture documentation.
• Vendor-shaped access: agents use each system’s familiar API shape, pagination, error codes, and MCP tools instead of a bespoke mock interface, omarsar0's breakdown notes.
• Cross-system work: a renewal in Salesforce, a support ticket in Zendesk, and a Slack message can form one timeline that an agent must join and interpret, the Eon launch post explains.

Era’s repeatability comes from rebuilding the same graph rather than merely restoring a database snapshot. rohanpaul_ai's report describes resetting the company and rerunning identical tasks after changing a model or prompt.

The architecture documentation says the generator uses a seed, a clock, and a day-state, with those same inputs rebuilding the company down to its IDs. It defines three states:

• Day 0: an empty tenant for a first full sync.
• Day 1: two years of trading, hiring, filing, conversations, and closing already populated.
• Day 2: 91 days later, with a quarter close, updated accounts, employees, deals, tickets, calls, files, and a shifted notion of “now.”

The same page says the generated history covers 730 days, with timestamps tied to local working hours, weekday patterns, holidays, and company growth rather than random row creation.

Era writes the records and therefore knows the answer key. Its code can score an agent’s answer without a human or language-model judge, rohanpaul_ai's report says.

Eon’s launch post reports two initial evaluations:

• Cross-system retrieval: nine models answered 33 questions, with three attempts per question and no code execution. Average accuracy was 92.6% on simple filtering, 39.6% on cross-system questions, and 3.7% on multi-hop questions.
• Hidden evidence: six models in two agent setups answered eight questions, again with three attempts each. The best agent got 18 of 24 attempts correct; four models answered six or fewer in either setup. Adding code execution did not improve the leading models.

The second evaluation included cases where Salesforce omitted a service credit but a Gong call contained a promise that had to be combined with Zendesk tickets to calculate what was owed.

Realism is also a configurable defect surface. In the launch discussion, omarsar0's question asked whether the same company could be generated with and without duplicates and junk rows; Era’s architecture page describes that as an opt-in overlay.

The documented controls include:

• Duplicate accounts, alias emails, pasted formatting, and blank optional fields.
• A defect manifest containing the defect kind, field, record, before value, and after value.
• Uneven volumes and relationship patterns, so customers can have different numbers of deals and tickets and accounts can have multiple contacts.

That manifest lets an eval score whether an agent found the duplicate or malformed record instead of merely guessing, according to the architecture documentation.

Vtrivedy10’s model puts production traces at the start of the loop and treats evals as more than a scorecard.

• Measurement device: the task, environment, expected outcome, and verifier define what “good” means.
• Hill-climbing data: the same evals provide the target while a team changes the model, tools, prompt, or harness.
• Simulation infrastructure: once the environment has enough fidelity, those variables can be changed and rerun as experiments.

The loop sends the winning configuration back toward production, where new trajectories become future eval material. Vtrivedy10 later called eval generation the hard part even as agents drive more harness discovery, in Vtrivedy10's reply.

Era is delivered as a developer-facing environment with connection details for each selected system. omarsar0's breakdown identifies vendor-compatible MCP and REST access as part of the launch design.

The documented starting command is:

Eon says the supported fleet includes Salesforce, HubSpot, Zendesk, Gong, Jira, Slack, SharePoint, Google Drive, Eon, Deel, and AWS services such as RDS, S3, and EC2, according to the launch post.

The same post says Era’s simulators are available as Docker images for service-container use in CI, with pytest, Node, and GitHub Actions examples. It also says the Era console itself can act as an MCP server so an agent can create and manage environments.

The environment is deliberately vendor-shaped rather than vendor-complete. Era’s architecture documentation says every record is simulated, the modeled systems are not affiliated with the vendors, and the implementation covers the surfaces a client uses rather than every corner of each API.

That boundary excludes production-specific behavior and real customer data. RuntimeWire’s report describes Era as a repeatable environment with known ground truth while keeping production testing separate.

Vtrivedy10 also noted that simulation stacks vary substantially by domain: simulating company databases is different from simulating visual modalities, Vtrivedy10's follow-up said.