Zenera Gym: A Synthetic World for Training Enterprise Agents

That world contains people, customers, contractors, projects, orders, messages, approvals, and obligations. Its state is distributed across applications built by different vendors, customized by different teams, and connected through integrations that are rarely simple. An action in one system can change what is possible in another. A technically valid API call can still be the wrong business decision.

To prepare an agent for that world, we need somewhere it can experience those relationships and consequences without putting real operations at risk.

That is the idea behind Zenera Gym: a synthetic enterprise environment for training and evaluating specialized agents.

Gym recreates the interfaces an agent uses and the coherent business reality behind them. REST APIs, tools exposed through Model Context Protocol (MCP) servers, email, calendars, ERP applications, and internal services become different ways of interacting with one synthetic world.

The distinctive part is how that world is constructed. Zenera agents build the simulated behavior and populate the connected state. The agent being trained operates inside the environment; Gym agents construct and maintain the environment around it.

The result is not just a set of convincing responses. It is a place where actions have consequences, those consequences persist, and an agent can practice doing enterprise work.

Giving an agent tools is relatively straightforward. Giving it a realistic place to practice using those tools is much harder.

Production is not a practice environment

An agent learns little about consequences if it is never allowed to take consequential actions. But unconstrained exploration in production is unacceptable.

A mistaken action can send a real email, change a supplier commitment, expose confidential information, modify an access policy, or release a payment. Even a reversible action may trigger notifications, integrations, or human work that cannot simply be undone.

An agent should not discover the meaning of "approve," "release," or "cancel" by experimenting on live business operations.

Staging rarely contains a complete business

Staging is valuable, but a working application is not the same as a complete operating environment.

A useful training scenario may require the same contractor to exist in six systems, a purchase order with the right history, a sequence of related messages, a calendar conflict, a pending approval, and an invoice in exactly the right state. Permissions must be appropriate. Integration jobs must behave realistically. The scenario must survive long enough for an agent to complete it.

Preparing that environment manually is expensive. Repeating the work for hundreds of variations is worse. Some external products have limited sandboxes. Some internal services have no maintained test instance. Copies of production data introduce privacy, access-control, and maintenance concerns of their own.

Staging also tends to represent the configurations and cases that engineers have already prepared, not the broad range of situations an agent needs to encounter.

Independent mocks recreate shapes, not a business

A conventional mock can return an invoice with the correct fields. Another mock can return a contractor. A third can return an email about a shipment.

But do they describe the same transaction?

If the agent updates the delivery date through one API, will the project system reflect the corresponding dependency? If it sends a message, can the recipient see it? If it deletes a resource, will a later search still return it?

Mocking each endpoint separately does not answer these questions.

At enterprise scale, the combined surface can span tens of thousands of REST operations and tools exposed by multiple MCP servers. The challenge is not just implementing their response schemas. It is maintaining meaningful behavior across the operations that participate in a workflow.

A credible enterprise world cannot be specified by an API schema alone. It needs three complementary inputs: the interface contract, the business semantics, and the world story.

API contracts define what can be called

OpenAPI and Swagger specifications describe REST operations, parameters, request bodies, response structures, and resource relationships. MCP tool definitions describe another interaction surface: the tools an agent can invoke and the inputs those tools accept.

These contracts tell Gym what the agent can call and what a structurally valid interaction looks like.

But structure is only the beginning.

Consider an internal operation:

POST /invoices/{invoiceId}/release

The schema may define an invoice identifier and a response containing a status. It may not explain whether "release" means removing a hold, approving an invoice, scheduling payment, or executing a transfer.

Those are very different actions.

Documentation and source code explain what calls mean

The meaning lives in the organization's semantic layer: its rules, domain concepts, state transitions, permissions, and integrations.

Relevant evidence can include:

• API descriptions and internal developer documentation.
• Business-process definitions and policy documents.
• Operational runbooks and support knowledge bases.
• Domain models and validation logic.
• Source code for controllers, services, and integration handlers.
• Tests that capture expected behavior and important exceptions.

For the invoice operation, that evidence might establish:

Releasing an invoice requires recorded delivery acceptance and finance approval. Release removes the payment hold. Settlement is scheduled separately by the payment service.

To recreate this behavior, Gym must preserve the distinction among acceptance, approval, release, and settlement. Returning "status": "released" to every request would match a response shape while teaching the agent the wrong business process.

Source code is particularly useful for proprietary APIs because important behavior is often absent from prose documentation. A service implementation may reveal an additional validation condition. A mapping function may show that an ERP vendor identifier corresponds to a differently named field in an internal system. An event handler may reveal that a state change triggers a downstream update rather than an immediate synchronous write.

The objective is to reconstruct the relevant behavior, not to copy an entire application or assume that a language model can infer every hidden rule.

Where documentation, tests, and source code disagree, the intended behavior needs to be resolved explicitly. Otherwise, a simulator can become confidently wrong.

The world story defines what is happening

The story specifies a particular business reality.

It describes who exists, what they are trying to accomplish, which transactions and commitments already exist, what has happened, and which unresolved conditions the agent will encounter.

For example:

Northstar Manufacturing is replacing a controller on production line 4. Apex Services is the installation contractor. Purchase order PO-731 covers the controller and installation. The planned shutdown ends Friday at 18:00. Apex has reported a shipment delay. Its proposed replacement technician does not yet have current site certification. Invoice INV-204 is on hold until installation is accepted. Finance has not authorized an exception.

This short description has consequences across the environment.

SAP needs the relevant contractor and purchase order. Email needs a plausible conversation history. The internal contractor service needs the technician and certification state. The calendar needs the shutdown window. Jira needs the installation task and its dependencies. The payment service needs an invoice whose state agrees with the acceptance policy.

The story is not decorative background attached to random sample data. It guides the construction of the scenario's connected state.

Negative facts matter as much as positive facts

A good story specifies not only what exists but also what does not.

If no finance exception has been approved, searching for an approval must not cause the environment to invent one. If the replacement technician lacks certification, reading another endpoint must not produce a valid certificate merely because it would help complete the task.

The environment must preserve inconvenient facts.

Otherwise, an agent can learn to search until the simulator supplies a convenient answer rather than learning to handle a genuinely blocked workflow.

World truth is not automatically agent knowledge

The story can contain information that is hidden from the agent under training.

Gym may know why a shipment is delayed, that a contractor will accept a particular alternative, or that a record is stale. The agent should discover those facts only through the observations available to its role.

The scenario definition belongs to the environment. It is not a privileged briefing that should silently leak into the agent's context.

The three inputs should not be confused:

Existing world state adds the fourth element: what has happened since the run began.

Return to the delayed controller installation.

The agent's job is not simply to acknowledge the email. It needs to determine whether there is an acceptable recovery plan and coordinate it within policy.

First, establish the situation

The agent reads the email and identifies Apex Services. It resolves that company to the appropriate contractor and vendor records.

It checks purchase order PO-731, finds the installation task, and reads the shutdown window. The revised delivery estimate conflicts with the original schedule.

An internal contractor API reveals a further constraint: the proposed replacement technician does not have current site certification.

A poor agent might immediately reschedule the meeting and tell everyone the issue is resolved.

A better agent recognizes that moving a calendar event does not remove the certification requirement or extend a production shutdown.

Then, communicate through the simulated world

The agent sends a clarification using the simulated Gmail API. It asks whether Apex can provide a certified technician within the remaining window.

That message becomes an event in the shared world.

The contractor can receive it through a simulated Microsoft email interface. It is not a separate, independently generated message that merely resembles the original. The sender and recipient views correspond to the same communication, even though provider-specific identifiers and payload structures differ.

When the scenario calls for an external participant response, a Gym-side participant can respond according to its role, knowledge, and constraints. That participant should not know the task agent's hidden reasoning or automatically agree to every request.

Finally, observe and manage the consequences

Suppose Apex can provide a certified technician, but only if delivery arrives before a specified cutoff.

The agent can record a conditional recovery plan, update the project task, and request confirmation from the shutdown owner. It must distinguish a proposed schedule from an approved one.

If the required approval never arrives, escalation may be the correct outcome. If delivery misses the cutoff, the plan must change again.

Meanwhile, invoice INV-204 remains on hold. An email promising delivery is not proof of acceptance. A project status update is not finance approval. The environment must preserve those distinctions across tools.

This is the difference between answering an API call and simulating an operating environment.

Gym is the environment in which experience happens. A training or evaluation process uses that experience.

Keeping those roles separate is important. A simulator does not, by itself, define the learning algorithm, reward function, or deployment decision.

Capture trajectories, not just final answers

A useful run produces more than an agent's final message.

It includes the observations available at each step, the actions taken, tool results, relevant state transitions, failures, retries, and final world state.

These trajectories make it possible to distinguish an agent that solved the problem correctly from one that reached an apparently successful result by violating policy or benefiting from a simulator defect.

The experience can support:

• Refining instructions and workflow skills.
• Improving tool selection and error recovery.
• Comparing model and agent configurations.
• Identifying missing knowledge or ambiguous policies.
• Collecting demonstrations and recovery examples.
• Supplying trajectories to a model-training pipeline.
• Running regression evaluations after agent changes.

Measure outcomes and constraints together

For the installation scenario, "the agent sent an email" is not a sufficient success criterion.

More meaningful questions include:

• Did it identify the correct order, project, and contractor?
• Did it verify certification and scheduling constraints?
• Was a revised commitment actually authorized?
• Did it preserve the invoice hold until the required conditions were met?
• Did its final report match the state of the systems?
• If no valid plan existed, did it escalate with the relevant evidence?

An agent that completes the nominal task by bypassing an approval should not receive the same result as one that follows the process.

Likewise, an agent that correctly identifies an impossible task should not be penalized simply because no installation was scheduled.

Where useful, measure efficiency as well: tool calls, unnecessary writes, elapsed time, and model cost. But speed should not compensate for violating a hard constraint.

The environment should not grade itself uncritically

Gym agents help construct the environment. They should not be the sole authority declaring that an agent's work is correct.

Use explicit outcome checks wherever possible: inspect persisted state, verify required relationships, confirm that forbidden actions did not occur, and test business invariants.

Model-based assessment can help with communication quality or ambiguous evidence, but it should complement observable checks rather than replace them.

The environment itself also needs validation. Cross-provider message delivery, denied writes, absent approvals, and duplicate requests should behave according to their defined contracts. Otherwise, a high score may measure adaptation to simulator mistakes.

Separate practice from held-out evaluation

An agent can overfit to a story just as it can overfit to a dataset.

If every scenario contains the same contractor, the same endpoint sequence, and the same successful resolution, the agent may learn a script rather than transferable behavior.

Held-out evaluation should vary entities, constraints, timing, workflow structure, and failure conditions. Evaluation scenarios and expected outcomes should not leak into the agent's training context.

Repeatable comparisons also require more than a random seed. The starting world, generated behavior, relevant configurations, and external-participant behavior need to be controlled or recorded. Where outcomes are stochastic, evaluate multiple runs rather than treating one favorable result as evidence of reliability.

Isolation is part of evaluation quality

A synthetic environment must remain separate from production destinations, credentials, and data. Routing an agent's email tool to Gym is not sufficient if another tool can still reach a live payment service.

Simulation also does not automatically make inputs safe. Source code, documentation, and scenario material may contain confidential information. They require appropriate access controls, model-provider policies, and handling.

The goal is not merely to avoid real writes. It is to establish a controlled boundary around the entire run, including what the agent can read, what it can contact, and where its outputs can go.