-
-
-
-
-
Execution Plan based on simulation
-
Simulation results of multiple options triggered by the agent
-
-
Architecture Diagram
INOEMA — Simulate Before You Execute
Inspiration
AI agents are becoming increasingly capable of making decisions and performing actions autonomously. But there is a fundamental problem: what happens when an AI agent makes the wrong decision and that decision has real-world consequences?
An agent might decide to retry a failed payment, modify a transaction strategy, or trigger an operational workflow. Executing that decision directly can introduce financial losses, duplicate operations, or unintended consequences.
We wanted to explore a different approach.
What if an AI agent could simulate the consequences of its decisions, evaluate different strategies, validate constraints, and only then produce an execution plan?
That idea became INOEMA — Simulate Before You Execute.
For the PayPal AI Hackathon, we applied this broader vision to a concrete problem: payment recovery and resilience.
What We Built
INOEMA Payments is an AI-powered payment recovery simulation and decision-validation platform.
Instead of blindly retrying failed payments, the platform explores recovery strategies, evaluates their expected outcomes, and applies deterministic safety checks before allowing an execution plan to proceed.
The system brings together four major stages:
- Simulate: Model payment failures, processing delays, retries, and recovery scenarios using discrete-event simulation.
- Optimize: Explore different retry policies and recovery strategies using Monte Carlo experiments, with a Gemini-powered agent coordinating the exploration.
- Validate: Evaluate candidate strategies against deterministic constraints, confidence thresholds, feasibility checks, and execution safety rules.
- Execute: Compile validated decisions into structured execution plans and demonstrate guarded payment operations through PayPal Sandbox.
How We Built It
We built INOEMA using Python, SimPy, NumPy, Pandas, SQLite, Streamlit, and Google's Gemini API.
1. Payment Simulation Engine
We developed a discrete-event simulation engine using SimPy to model payment processing systems, including worker capacity, processing-time distributions, failure probabilities, retry schedules, and recovery windows.
Monte Carlo experiments allow us to compare different policies across multiple scenarios. We also incorporated reproducible random seeds, confidence intervals, and sensitivity analysis to understand how assumptions affect outcomes.
2. Agentic Optimization with Gemini
We integrated Gemini as the reasoning layer for exploring payment recovery strategies.
Rather than allowing the agent to directly interact with the simulation engine, we exposed capabilities through a dedicated Model Context Protocol (MCP) server.
The agent can use tools for simulation, experimentation, sensitivity analysis, and evidence retrieval. Candidate strategies are subsequently evaluated by a deterministic objective and constraint evaluator.
This separation ensures that an LLM's recommendation is not automatically treated as an executable decision.
3. Execution Bridge and Safety Layer
One of the most important components is the execution bridge.
It takes persisted optimization results, checks their completeness and confidence, verifies policy feasibility and supported constraints, and compiles eligible decisions into a versioned execution plan.
The executor enforces safeguards such as:
- Retry budgets and recovery windows.
- Idempotency protection.
- Terminal failure handling.
- Buyer approval requirements.
- Completed-payment protection.
- Explicit confirmation before guarded payment operations.
Incomplete or low-confidence results are rejected by default. A demonstration override can expose such results for inspection, but it does not bypass feasibility or supported-constraint checks.
4. PayPal Sandbox Integration
We integrated PayPal Orders APIs to demonstrate the payment lifecycle, including order creation, buyer approval, capture, and independent verification.
We successfully completed and verified a USD 10 PayPal Sandbox payment.
The capture was manually resumed by an operator through the guarded workflow. It was not triggered by Gemini's recommendation or by the execution bridge. This distinction is important: the Sandbox integration validates the payment mechanics, while the execution bridge separately demonstrates the policy-to-plan safety architecture.
5. Unified Dashboard
We built a Streamlit dashboard with six Payments sections:
- Overview
- Policy Optimization
- Experiments
- PayPal Sandbox
- Agent Execution Traces
- Execution Plan
The dashboard distinguishes simulated outcomes, agent-derived results, actual Sandbox evidence, and system-generated information so that different evidence sources are not confused.
Challenges We Faced
Balancing AI autonomy with deterministic safety
We wanted Gemini to explore strategies and reason about possible outcomes, but we did not want an LLM to have unrestricted control over financial operations. Designing the boundary between agent reasoning and deterministic execution validation was one of our biggest engineering challenges.
Building a meaningful simulation
A simulation is only useful when its assumptions are explicit and its results are reproducible. Modeling processing delays, failures, worker contention, retries, and recovery windows required careful design and testing.
Integrating real payment workflows safely
PayPal's order lifecycle involves buyer approval, capture authorization, idempotency, ambiguous API responses, and independent verification. We implemented safeguards to avoid duplicate captures and prevent operations on completed payments.
Working within API and development constraints
Gemini API quota limitations interrupted our live agent validation run. We therefore made sure incomplete results were not treated as approved decisions, and retained explicit confidence and completeness gates rather than presenting an incomplete run as a successful end-to-end execution.
What We Learned
This project taught us that building a useful agentic system is not just about giving an LLM more tools or autonomy.
The surrounding infrastructure matters just as much.
We learned how to:
- Design simulation-driven decision workflows.
- Integrate Gemini with custom MCP tools.
- Combine probabilistic simulation with deterministic evaluation.
- Build reproducible Monte Carlo experiments.
- Design execution plans with safety constraints and idempotency.
- Integrate PayPal Sandbox APIs and verify payment states.
- Separate simulated evidence from actual external-system evidence.
Most importantly, we explored a principle that we believe will become increasingly important as autonomous agents enter financial and operational systems:
An AI agent should not have to learn the consequences of an action by executing it in the real world. It should be able to simulate, validate, and understand those consequences first.
What's Next
The PayPal implementation is our first application of INOEMA's simulation-first architecture.
Our next steps include connecting validated agent-generated policies to a fully integrated execution workflow, improving simulation calibration using real operational data, expanding scenario coverage, and exploring applications beyond payments.
We see INOEMA as a potential decision-validation infrastructure layer for autonomous AI systems — helping bridge the gap between what an agent decides and what it is safe to execute.
INOEMA — Simulate Before You Execute.
Built With
- agentic-ai
- ai-agents
- api-integration
- artificial-intelligence
- automation
- cloud-computing
- decision-intelligence
- fintech
- google-gemini
- machine-learning
- model-context-protocol-(mcp)
- monte-carlo-simulation
- numpy
- optimization
- payment-processing
- payment-recovery
- paypal
- python
- reliability-engineering
- risk-management
- simpy
- simulation
- sqlite
- streamlit
