ganeshkota/agent-app

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:

python main.py

Run the revenue assurance worker:

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:

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 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:

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:

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

python -m unittest discover -s tests -v

VS Code tasks

• Run Agent CLI
• Run Unit Tests

Build package

python -m pip install build
python -m build