# Agent App Starter workspace that now includes a first working slice of an enterprise Revenue Assurance and Order-to-Cash control tower. ## Implemented milestone This repository implements the first practical path end to end: - 1 customer - 1 contract - 1 sales order and usage summary - 1 incorrect invoice (discount mismatch) - Deterministic reconciliation detects a $36,000 variance - Case is created - A real model-backed agent can call skills as tools when Foundry model settings are configured - Recommendation is produced with evidence and approval routing ## Phased roadmap 1. Phase 1 — Python implementation - Domain models, reconciliation rules, case creation, and demo data live in the revenue assurance package. 2. Phase 2 — agentic implementation - The workflow can call a Foundry-backed model using the existing skills as tools for investigation. 3. Phase 3 — skills implementation - Read-only skills provide customer, contract, usage, invoice, and case lookup context to the agent. 4. Phase 4 — agent with tools implementation - The investigation agent uses tool calling and deterministic fallback behavior to stay robust when the model is unavailable. 5. Phase 5 — evaluations - Add test data, evaluation prompts, and confidence/approval quality tracking for production hardening. ## Structure - apps/reconciliation_worker/: runnable reconciliation worker entrypoint - docs/business-requirements.md: one-page business requirements document - src/agent_app/: starter agent package - src/agent_app/revenue_assurance/: reconciliation, skills, case management, and investigation agent - tests/: unit tests for starter and revenue-assurance modules ## Run locally Run the starter chat-style agent: ```bash python main.py ``` Run the revenue assurance worker: ```bash python -m apps.reconciliation_worker.run ``` To enable the real agentic Foundry-backed path, set: - `REVENUE_ASSURANCE_AZURE_OPENAI_ENDPOINT` or `AZURE_OPENAI_ENDPOINT` - `REVENUE_ASSURANCE_MODEL_DEPLOYMENT` or `AZURE_OPENAI_DEPLOYMENT_NAME` - `REVENUE_ASSURANCE_AZURE_OPENAI_API_KEY` or `AZURE_OPENAI_API_KEY` - Optional: `REVENUE_ASSURANCE_AZURE_OPENAI_API_VERSION` or `AZURE_OPENAI_API_VERSION` You can also point the app at a JSON config file using `REVENUE_ASSURANCE_CONFIG_PATH`. An example file is available in `examples/revenue_assurance_config.json`. For a local AML-style payload, run: ```bash python -m agent_app.revenue_assurance.aml_runner --config examples/revenue_assurance_config.json ``` To submit a real Azure ML command job, edit [examples/aml_submit_config.json](examples/aml_submit_config.json) and fill in: - `subscription_id` - `resource_group` - `workspace_name` - Optional: `compute_name` - Optional: `code_path` - Optional: `environment_image` - Optional: `experiment_name` - Optional: `display_name` - `revenue_assurance_config_path` if you want to point to a different model config file Then run: ```bash python -m agent_app.revenue_assurance.aml_submit --config examples/aml_submit_config.json ``` To submit a Pipeline job with component graph visualization (without replacing the command-job path), run: ```bash python -m agent_app.revenue_assurance.aml_submit --mode pipeline --config examples/aml_submit_config.json ``` Why two modes exist: - Command job mode (`--mode command`, default) runs one standalone command and is usually fastest for operational runs. - Pipeline job mode (`--mode pipeline`) wraps the same workload into a pipeline step so Azure ML displays a component graph and child-step lineage. If you prefer environment variables, the submitter also understands: - `AML_SUBSCRIPTION_ID` - `AML_RESOURCE_GROUP` - `AML_WORKSPACE_NAME` - `AML_COMPUTE_NAME` Tip for safe sharing: - Keep `examples/*.json` as placeholders for GitHub. - Put your real values in local files like `examples/aml_submit_config.local.json` and `examples/revenue_assurance_config.local.json` (ignored by git). ## Test ```bash python -m unittest discover -s tests -v ``` ## VS Code tasks - Run Agent CLI - Run Unit Tests ## Build package ```bash python -m pip install build python -m build ```