Do Enterprise Systems Need Learned World Models? The Importance of Context to Infer Dynamics
Abstract: World models enable agents to anticipate the effects of their actions by internalizing environment dynamics. In enterprise systems, however, these dynamics are often defined by tenant-specific business logic that varies across deployments and evolves over time, making models trained on historical transitions brittle under deployment shift. We ask a question the world-models literature has not addressed: when the rules can be read at inference time, does an agent still need to learn them? We argue, and demonstrate empirically, that in settings where transition dynamics are configurable and readable, runtime discovery complements offline training by grounding predictions in the active system instance. We propose enterprise discovery agents, which recover relevant transition dynamics at runtime by reading the system's configuration rather than relying solely on internalized representations. We introduce CascadeBench, a reasoning-focused benchmark for enterprise cascade prediction that adopts the evaluation methodology of World of Workflows on diverse synthetic environments, and use it together with deployment-shift evaluation to show that offline-trained world models can perform well in-distribution but degrade as dynamics change, whereas discovery-based agents are more robust under shift by grounding their predictions in the current instance. Our findings suggest that, in configurable enterprise environments, agents should not rely solely on fixed internalized dynamics, but should incorporate mechanisms for discovering relevant transition logic at runtime.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
What is this paper about?
Imagine you’re playing a game where the rules can change from one house to another—and you’re allowed to open the rulebook before you move. This paper asks: if the rules of a computer system are written down and can be read at the moment you need them, do we really need an AI that tries to memorize the rules ahead of time?
The authors study “enterprise systems” (big software used by companies), where each customer can set up their own rules and workflows. They compare two ways an AI might predict what will happen after an action:
- Learn the rules from past examples and try to remember them (“world models”).
- Read the rules that are actually active right now and think through the consequences (“discovery agents”).
They also introduce a new test, called CascadeBench, to check which approach works better when rules vary across companies and change over time.
What questions did the researchers ask?
- Can AIs that memorize how systems behave (world models) handle new companies with different, changing rules?
- If the system’s rules are available to read, does it work better for an AI to look them up at runtime instead of relying only on memory?
- How do different approaches compare when actions cause chain reactions (“cascades”) across the system?
How did they study it?
To make this understandable, think of a help desk ticket in a company’s system:
- You change a ticket’s priority to High.
- That change might trigger a rule to alert a manager, start a timer (SLA), or update other fields.
- One small update can cause a chain reaction across the system—like knocking over one domino and watching many fall.
Here’s their approach, in simple terms:
- They built an “Enterprise Gym” and a benchmark called CascadeBench:
- Enterprise Gym: They set up many different fake companies with different sets of rules (like different “houses” with different rulebooks). Then they performed real actions and recorded exactly what the system changed.
- CascadeBench: A test focused on predicting these chain reactions. It hides memorization shortcuts and focuses on reasoning: given the current state and an action, what will change next?
- They tested three types of AI predictors: 1) Prompted baseline: A general LLM that reads some context and guesses the next changes. 2) Learned world model: A model fine-tuned (trained) on lots of past examples to “internalize” how changes usually play out. 3) Discovery agent: An AI that, at prediction time, actively looks up the current company’s rules and then reasons step-by-step about what will happen—without changing its own parameters.
- They organized system behavior into three “tiers” of difficulty:
- Tier 1: Simple effects you can figure out from the database design (like a default value or a required field).
- Tier 2: Cascades driven by written rules (like “if priority increases, set escalation to true and notify manager”).
- Tier 3: Outcomes that depend on hidden engine details (like which of several rules runs first), which are partly visible but not fully written down.
What did they find, and why does it matter?
Here are the main results, in plain language:
- Memorizing works well only when nothing has changed:
- Models trained on past data (world models) did great on environments similar to their training data.
- But when they faced new companies with different rules, their accuracy dropped a lot.
- Reading the rules at runtime makes predictions more robust:
- Discovery agents that looked up live rules at prediction time handled new, different environments much better.
- This advantage showed up especially when actions triggered multi-step cascades (Tier 2), because the exact rules mattered.
- Providing the rules is a game-changer:
- When the rules were given in the input or retrieved by the agent, all models improved, because they could anchor their reasoning in what’s actually active now.
- Without access to rules, even strong models struggled, especially on cascades.
- Discovery helps across multiple steps:
- Even when predicting several steps ahead (where mistakes can snowball), discovery agents stayed more accurate than prompted models that didn’t retrieve rules, because they could keep grounding their reasoning in the live setup.
In short: in systems where rules are readable and change a lot, looking them up at runtime beats relying only on memory.
What could this change in the real world?
- Smarter, more reliable enterprise assistants:
- Help desk bots, IT ops assistants, and workflow planners could better predict what will happen if they change something, even as each company customizes its own rules.
- Less retraining, more adaptability:
- Instead of constantly retraining AI every time a company updates a rule, discovery agents can adjust on the fly by reading the current configuration.
- A blended strategy:
- The best future systems will probably mix both ideas: keep some learned “common sense” about typical patterns, and combine it with live rule-reading to avoid mistakes when things change.
Lastly, the authors note limits: discovery only works if the agent is allowed to read the rules and knows how to use the tools to retrieve them. Some tricky effects (like exact execution order of multiple rules) may still be hard to predict. But overall, the message is clear—when the rulebook is available and changing, read it.
Knowledge Gaps
Unresolved knowledge gaps, limitations, and open questions
Below is a concise list of what remains missing, uncertain, or unexplored in the paper, framed to guide actionable future work:
- Cross-platform generality: All quantitative evaluation is on a single platform (ServiceNow). It is unclear whether discovery-based robustness holds on other configurable enterprise systems (e.g., Salesforce, SAP, Workday) with different rule engines and configuration models.
- Restricted-access settings: Discovery assumes readable business rules; performance and fallback strategies under realistic access controls (partial visibility, redaction, API limits) are not evaluated.
- Retrieval policy learning: The agent’s retrieve-then-reason loop is heuristic. How to learn when/what/how much to retrieve (and in what order) to minimize errors, token budget, and latency remains open.
- Retrieval quality measurement: The paper does not quantify retrieval recall/precision for relevant rules, schema fragments, and records, nor how retrieval errors (false positives/negatives) drive prediction errors.
- Indexing and scaling: No study of retrieval infrastructure (index design, sharding, freshness) for large instances with thousands of rules; scalability and performance under realistic tenant sizes remain untested.
- Cost/latency trade-offs: End-to-end latency and cost of discovery (API calls, token usage) vs. relying on internalized models is not characterized—critical for production SLAs.
- Tier 3 coverage: Execution-order semantics, engine-internal prioritization, concurrency, and asynchronous triggers are only partially addressed. Instrumentation or static analysis needed to capture these effects is not developed.
- Time-based and asynchronous dynamics: SLAs, scheduled jobs, timers, and event queues introduce non-instantaneous transitions not fully evaluated by the current synchronous prediction setup.
- Mid-episode configuration drift: The system may change while the agent reasons (admins modify rules). Robustness to live updates and mechanisms for detecting and adapting to drift are not studied.
- Noisy/obsolete/conditional rules: Real configs include disabled, conflicting, scoped, or context-gated rules. How discovery filters non-applicable or stale artifacts and handles rule-versioning remains unexplored.
- Safe probing: While discovery “may” use probe actions, the implemented agent avoids execution. How to design safe, sandboxed probes and quantify their benefit vs. pure read-only retrieval is left open.
- Beyond IoU metrics: Evaluation focuses on field-diff IoU. Effects on cascade-path prediction, constraint satisfaction, side-effect localization across tables, and downstream task performance (planning/execution) are not assessed.
- Cascade path evaluation: Although cascade paths π are recorded, there is no quantitative evaluation of predicting or explaining the causal chain—important for interpretability and debugging.
- Representativeness of synthetic schemas: CascadeBench removes memorization but may diverge from real-world inter-table dependencies and script idioms; external validation against production-like configs is limited.
- Dataset sufficiency and diversity: With 27k transitions across 64 worlds, sample complexity for training and the breadth of covered rule patterns vs. the 1,596 pattern catalog are not analyzed.
- Comparative baselines: Missing comparisons to symbolic/static analysis approaches (e.g., parsing business rules into executable logic), program synthesis, or rule engine emulation as alternative to LLM-based reasoning.
- Hybrid learning + discovery: How to integrate priors with retrieval (e.g., retrieval-augmented training, policy learning for retrieval orchestration, memory of discovered rules across tasks) is proposed but not implemented.
- Handling partial observability: Not all determinants of transitions may be exposed (plugins, external scripts, third-party integrations). Strategies for inferring hidden factors or expressing uncertainty are not provided.
- Uncertainty and calibration: The agent does not quantify prediction confidence or detect out-of-scope dynamics; mechanisms to defer, request more context, or switch strategies under uncertainty are absent.
- Robustness to adversarial or malformed configs: Security and safety implications of reading untrusted configuration (prompt injection via rule text, crafted rule names) are not evaluated.
- Token/context constraints: Effects of long rule documents and large context windows on model performance, chunking/summarization strategies, and retrieval compression are not analyzed.
- Model-size sensitivity and training regimes: Results focus on 27–31B open-weight models with LoRA; behavior with smaller/larger backbones, full fine-tuning, and instruction-tuned models is not systematically explored.
- Formal conditions for discovery advantage: No theoretical analysis characterizes when reading at inference time dominates learned dynamics (e.g., bounds under configuration shift or Bayes risk comparisons).
- Multi-agent and concurrent changes: Interaction effects when multiple agents or users act concurrently on the same instance (race conditions, interleaving cascades) are not modeled or evaluated.
- Compliance and privacy constraints: Practical limits on exposing configuration (PII in rules, regulatory restrictions) and how to deploy discovery agents under governance requirements are not addressed.
Practical Applications
Practical applications derived from the paper’s findings
This paper shows that in configurable enterprise environments, agents are more robust when they retrieve and reason over live configuration (business rules, workflows, SLAs) at inference time rather than relying solely on learned, fixed world models. It also introduces the Enterprise Gym/CascadeBench tooling and a three-tier taxonomy of transition complexity. Below are actionable applications grouped by deployment readiness.
Immediate Applications
- Configuration-aware enterprise agents for safe action planning
- Use case: Before acting (e.g., updating a ticket, changing a field), agents retrieve active business rules/SLA definitions and predict cascades to select safe, compliant actions.
- Sectors: Software/IT (ITSM, ITOM, CRM, ERP), healthcare administration, finance operations, government services.
- Potential tools/products/workflows: “Discovery Agent” middleware (tool-enabled LLM orchestration), rule-retriever connectors for ServiceNow/Salesforce, policy-aware action planners embedded in ticketing forms and chatbots.
- Assumptions/dependencies: Read API access to schemas/rules/logs; reliable tool use; latency budget for retrieval; Tier 1–2 logic is machine-readable.
- “What-if” change-impact previews (dry runs)
- Use case: Preview the field-level state diffs and cascades an action will trigger before execution (e.g., when editing records, deploying a rule, or triggering an automation).
- Sectors: IT operations, DevOps/CI-CD, CRM/ERP admins, MSPs.
- Potential tools/products/workflows: Form-level “Impact Preview” widgets; CI/CD guardrails that block risky changes; PR bots that comment on predicted cascades.
- Assumptions/dependencies: Up-to-date rule retrieval; accurate mapping from rules to field diffs; non-destructive “simulate-by-reading” mode.
- Cross-tenant portable automations without retraining
- Use case: Agents and automations that generalize across customers/tenants by retrieving live configuration at inference time instead of depending on a trained world model.
- Sectors: SaaS vendors, system integrators, MSPs.
- Potential tools/products/workflows: Multi-tenant agent SDK with configuration adapters; “bring-your-own-tenant” onboarding flows.
- Assumptions/dependencies: Standardized configuration representations; permission boundaries respected; throttling/quotas for API calls.
- Cascade debugging and root-cause analysis (RCA)
- Use case: Reconstruct why a state change occurred by correlating audit logs with retrieved rule definitions and cascade paths.
- Sectors: SRE/IT operations, regulated industries (finance, healthcare, public sector).
- Potential tools/products/workflows: “Cascade Explorer” UI; RCA reports that trace table/field changes to specific business rules.
- Assumptions/dependencies: High-quality audit logs; rule-to-change attribution metadata; log retention/compliance.
- Test generation and coverage for business rules
- Use case: Automatically generate regression tests covering rule branches and cascades; detect gaps as rules evolve.
- Sectors: QA for enterprise applications; platform engineering.
- Potential tools/products/workflows: Test-case generators that read rules and seed records; coverage reports for Tier 1–2 transitions; integration with existing test frameworks.
- Assumptions/dependencies: Deterministic rule evaluation in test sandboxes; seeded initial states; mapping of conditions to test inputs.
- Inline compliance and approval checks
- Use case: Pre-flight compliance validation (e.g., approvals, segregation-of-duties, SLA adherence) by interpreting current approval policies and SLAs before an action is executed.
- Sectors: Finance (SOX), healthcare (HIPAA), government (FedRAMP), large enterprises with internal governance.
- Potential tools/products/workflows: Policy-as-code mappers from rule records; “Compliance Preview” in workflow designers; continuous controls monitoring via discovery.
- Assumptions/dependencies: Policies encoded in rules or mappable from them; up-to-date policy catalogs; access controls allow read-only inspection.
- Retrieval-augmented reasoning for enterprise support
- Use case: Support assistants that fetch relevant business rules and schemas to answer “why did X happen?” or “what will Y do?” more accurately.
- Sectors: Customer support, IT service desks, internal enablement.
- Potential tools/products/workflows: Vector indices for rules; retrieval chains that filter to task-relevant rules c̃; response templates citing rule sources.
- Assumptions/dependencies: Continual re-indexing as configurations change; prompt/tool reliability; PII redaction.
- Benchmarking and academic evaluation using CascadeBench
- Use case: Evaluate agents’ robustness to configuration/deployment shift independent of memorized schemas; compare prompting, fine-tuning, and discovery.
- Sectors: Academia, AI research groups, enterprise AI R&D.
- Potential tools/products/workflows: Adoption of CascadeBench and Enterprise Gym for model evaluation; tier-stratified reporting and ablations.
- Assumptions/dependencies: Public or licensed access to the benchmark; reproducible setup; compute resources.
- Safer personal and SMB automations (daily life)
- Use case: In smart home platforms (e.g., Home Assistant, IFTTT) or SMB tools, preview and explain automation cascades by reading active automations.
- Sectors: Smart homes, small businesses, facilities.
- Potential tools/products/workflows: “Automation Impact Preview” in rule editors; conflict detectors for overlapping automations.
- Assumptions/dependencies: Exposed, readable automations; connectors; execution-order semantics may limit Tier 3 prediction.
Long-Term Applications
- Hybrid agents that learn “when/what/how” to retrieve
- Use case: Combine learned priors with runtime discovery so agents adaptively decide if retrieval is needed, which artifacts to fetch, and how to compose them.
- Sectors: Enterprise AI platforms; autonomous operations.
- Potential tools/products/workflows: Retrieval-aware planners; RL/meta-learned retrieval policies; cost/latency–accuracy trade-off optimizers.
- Assumptions/dependencies: Training datasets with retrieval supervision; telemetry to learn retrieval policies; sustained tool reliability.
- Platform standards and policy for rule observability
- Use case: Industry standards mandating read-only, auditable APIs for business rules/workflows to enable safe AI agents and compliance.
- Sectors: Policy/regulation, SaaS vendors, standards bodies.
- Potential tools/products/workflows: “RuleBOM”/“ConfigBOM” artifacts analogous to SBOMs; auditability schemas; certification programs.
- Assumptions/dependencies: Vendor buy-in; security reviews; alignment with privacy requirements.
- Tier 3 (execution semantics) inference and verification
- Use case: Resolve execution-order and engine-internal behaviors via formal methods and non-destructive probe experiments to close the gap where static artifacts are insufficient.
- Sectors: Safety-critical IT, healthcare, fintech, government.
- Potential tools/products/workflows: Probe schedulers; partial-order/temporal logic verification for workflow engines; causal inference over logs.
- Assumptions/dependencies: Safe sandboxing; engine instrumentation; agreement on probe safety/risk scoring.
- Autonomous, policy-governed operations (“autopilot” agents)
- Use case: Agents that continuously retrieve rules, plan actions, verify compliance, execute safely, and adapt to configuration changes without retraining.
- Sectors: Cloud/IT operations, fintech operations, hospital administration.
- Potential tools/products/workflows: Closed-loop controllers with discovery hooks; explainability dashboards tying actions to rules/policies.
- Assumptions/dependencies: High availability of APIs; robust fallback/kill-switches; strong audit trails and human-in-the-loop oversight.
- Cross-platform discovery SDKs (beyond one vendor)
- Use case: Generalize discovery agents to CRM (Salesforce), ERP (SAP), EHR (Epic/Cerner), building management systems, and industrial control platforms.
- Sectors: Software, healthcare, manufacturing, energy/buildings.
- Potential tools/products/workflows: Connector libraries for rule/schema retrieval; unified configuration ontology; adapter patterns.
- Assumptions/dependencies: Vendor APIs and licensing; variability in configuration models; careful PII/PHI handling.
- Migration/upgrade “change twin” simulators
- Use case: Predict behavior after rule changes or platform upgrades by comparing cascades across versions/branches and suggesting remediations.
- Sectors: Large enterprises, MSPs, platform vendors.
- Potential tools/products/workflows: Differential cascade visualizers; automated rule refactoring suggestions; upgrade risk scoring.
- Assumptions/dependencies: Versioned rule stores; high-fidelity sandboxes; mapping between legacy and new execution semantics.
- Retrieval economics and scheduling optimization
- Use case: Optimize retrieval frequency, breadth, and depth to balance latency, cost, and accuracy for production agents.
- Sectors: AI platform engineering, FinOps.
- Potential tools/products/workflows: Telemetry-driven retrieval schedulers; caching layers; budget-aware planning.
- Assumptions/dependencies: Rich runtime metrics; cost-accounting hooks; service-level objectives.
- Workforce education and curriculum on cascade reasoning
- Use case: Training programs that use Enterprise Gym/CascadeBench to teach rule composition, cascade prediction, and safe automation design.
- Sectors: Academia, corporate training, professional certifications.
- Potential tools/products/workflows: Courseware, labs, certification exams based on tiered transition complexity.
- Assumptions/dependencies: Stable benchmark access; instructor resources.
- Continuous security posture and misconfiguration detection
- Use case: Discover misconfigured or conflicting rules that create security or privilege-escalation pathways; prioritize fixes based on cascade risk.
- Sectors: Enterprise security, GRC.
- Potential tools/products/workflows: Rule linters, conflict detectors, risk dashboards tied to discovery outputs.
- Assumptions/dependencies: Comprehensive rule visibility; defined risk models; SOC integration.
- Energy/building automation and digital twin alignment
- Use case: In building/facility management systems, retrieve automation graphs to predict cascades from setpoint changes and align with digital twins.
- Sectors: Energy, smart buildings, industrial IoT.
- Potential tools/products/workflows: “Setpoint impact” previews; BAS rule introspection adapters; twin consistency checks.
- Assumptions/dependencies: Standardized BAS models (e.g., Project Haystack/Brick); vendor APIs; safe test environments.
Notes on feasibility across all applications:
- The approach presumes read access to live configuration; without it, discovery degenerates to the prompted baseline.
- Reliability hinges on tool-use competence of the underlying LLM and the freshness/quality of retrieved artifacts and logs.
- Execution-order and engine-internal behaviors (Tier 3) may remain only partially observable; safe probe mechanisms and/or vendor support are often required.
- Privacy and access control constraints (e.g., PII/PHI) must be respected via redaction, scoping, and least-privilege access.
Glossary
- Access control lists: Permission lists that define which users or roles can access specific resources or operations in an enterprise system. "access control lists deployed on a particular customer's instance"
- Audit logs: System-generated records that chronologically capture actions and resulting changes, used here to trace cascades and ground truth transitions. "recording the resulting cascades through platform audit logs."
- Business rules: Declarative, configurable logic that governs automated actions and cascades in enterprise workflows. "real business rules execute"
- Cascade path: The ordered trace of tables and rules traversed by a triggered cascade resulting from an action. "the cascade path: the ordered sequence of tables touched and business rules attributed to each transition."
- CascadeBench: A benchmark designed to evaluate robustness and reasoning for enterprise cascade prediction under configuration and deployment shift. "We introduce CascadeBench, a reasoning-focused benchmark for enterprise cascade prediction"
- Configuration artifacts: Deployable, tenant-specific objects (e.g., rules, workflows) that determine system behavior. "tenant-specific configuration artifacts, such as business rules and workflows"
- Configuration shift: Changes in the deployed configuration (rules, workflows, policies) that alter transition dynamics and stress model robustness. "robustness under configuration and deployment shift"
- Contextual transition model: A dynamics formulation where next-state transitions depend on state, action, and the active instance configuration. "We formalize this as a contextual transition model."
- Deployment shift: Variation across different deployed instances (tenants) that causes learned models to degrade when moved across environments. "brittle under deployment shift."
- Distribution shift: Mismatch between the training distribution and test/deployment conditions that harms model performance. "reduce robustness under distribution shift."
- Enterprise discovery agents: Agents that recover transition logic at inference time by reading live configuration instead of relying solely on learned dynamics. "We propose enterprise discovery agents"
- Enterprise Gym: A live, non-simulated environment suite where worlds are deployed to collect ground-truth transitions via the real platform engine. "collected from Enterprise Gym"
- Execution-order resolution: Engine-specific semantics that determine the order and outcome when multiple rules interact, affecting observed transitions. "execution-order resolution and other engine-internal behaviors"
- Grounding (predictions): Anchoring predictions to the active system instance by using live configuration and state instead of only internalized knowledge. "by grounding predictions in the active system instance."
- In-distribution: Evaluation regime where test data matches the training configuration, often yielding higher performance than under shift. "perform well in-distribution but degrade as dynamics change"
- Instance configuration: The deployed set of rules, workflows, policies, SLAs, and ACLs that define a tenant’s runtime behavior. "the instance configuration (the collection of all business rules"
- IoU (Intersection over Union): A set-overlap metric used to compare predicted field-level diffs against ground truth; strict IoU requires exact value matches. "Strict IoU additionally requires the predicted value to match"
- IoU(T+F): A table-and-field-level IoU variant that credits correct identification of which table/field pairs change, regardless of exact values. "IoU(T+F) credits a prediction when it correctly identifies the affected (table, field) pair"
- Latent dynamics: Learned internal representations of environment evolution that support planning without predicting raw observations directly. "which learn latent dynamics to support planning and policy optimization."
- LoRA: A parameter-efficient fine-tuning method that adapts large models via low-rank updates. "with LoRA"
- Model-based reinforcement learning: A paradigm that separates a learned dynamics model from control/planning to improve sample efficiency and foresight. "forming the foundation of model-based reinforcement learning."
- Multi-tenant: A platform architecture where multiple customers (tenants) share infrastructure but differ in configuration, inducing cross-tenant variability. "multi-tenant enterprise environments"
- Oracle (for retrieval): An evaluation setting where the relevant rules are provided directly in the prompt, serving as an upper bound for discovery. "w/ BR supplies the relevant business rules in the prompt (an oracle for retrieval)"
- Retrieve-then-reason: An inference strategy where the agent first fetches relevant configuration/context and then reasons to predict outcomes. "the discovery agent follows a retrieve-then-reason strategy."
- Rollout horizon: The number of future steps over which predictions are sequenced, with accuracy typically degrading as depth increases. "as the rollout horizon increases"
- Sandboxes: Isolated execution environments used to safely run candidate actions and collect clean traces. "executed in isolated sandboxes"
- Service Level Agreements (SLAs): Formalized service performance contracts whose timers and states can be triggered and tracked during cascades. "Service Level Agreements (SLAs)"
- State delta: The subset of state that changes between consecutive steps, modeled as the difference from pre- to post-action state. "we effectively model a state delta, Δ s_t, roughly corresponding to s_{t+1} − s_t"
- State diff: The structured representation of field-level changes predicted or observed after an action. "a state diff over a database with thousands of fields"
- sys_audit: A platform audit table used to recover causal state changes resulting from executed actions. "recovered from sys_audit"
- Synthetic schemas: Artificially constructed table structures used to prevent memorization and focus evaluation on reasoning. "built on synthetic schemas that do not appear in real platform deployments"
- Tenant-specific: Pertaining to configuration or logic customized per customer instance, leading to differing dynamics across deployments. "tenant-specific business logic"
- Transition complexity: A tiered taxonomy of difficulty for predicting effects, from schema-determined to rule-composed and execution-dependent. "three levels of transition complexity"
- World models: Predictive models that internalize environment dynamics to anticipate the effects of actions for planning and reasoning. "World models enable agents to anticipate the effects of their actions"
- World of Workflows (WoW): A benchmark that evaluates agents’ ability to predict state transitions and constraints in enterprise workflows. "World of Workflows (WoW)"
Collections
Sign up for free to add this paper to one or more collections.