Agentic Workflow Automation for Financial Operations

ramp · Finance · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Financial-operations workflow automation with production AI agents

Ramp needed to automate finance workflows across expenses, policies, accounting, approvals, data support, and internal engineering without leaving each product team to build isolated agents, bespoke tool integrations, and one-off model infrastructure.

Constraints:

• Finance workflows involve sensitive spend, policies, ERP context, receipts, employee hierarchy, accounting codes, and human approvals.
• Early decentralized agent experiments produced multiple implementations of the same patterns.
• Policy decisions required multimodal reasoning over receipts, transaction data, policy documents, employee roles, and contextual limits.
• Increasing agent autonomy reduced explainability and traceability.
• Customer trust had to build from suggestions before fully autonomous approvals.
• Internal product teams needed shared model-provider, batch-processing, tool-catalog, tracing, and cost infrastructure.

Architecture

Ramp moved from many siloed agents toward a shared platform: Omnichat provides a single conversational surface, an in-house lightweight agent framework orchestrates tools and deterministic playbooks, a shared tool catalog exposes finance and internal APIs, the policy agent reasons over expense policies plus receipt/transaction/HRIS context, human review and weekly labeling produce ground truth, evals run early and in CI, an applied-AI service standardizes model provider APIs, batch handling, structured outputs, and cost tracing, and Ramp Inspect applies the same context/tool approach to background coding agents that create branches, use company context, run tests, and collaborate with humans.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  customer-user[Customer user] --> omnichat[Omnichat]
  customer-user --> policy-agent[Policy agent]
  omnichat --> agent-framework[Agent framework]
  omnichat --> playbook-engine[Playbook engine]
  agent-framework --> tool-catalog[Tool catalog]
  agent-framework --> policy-agent
  agent-framework --> accounting-code-agent[Accounting code agent]
  agent-framework --> playbook-engine
  playbook-engine --> tool-catalog
  receipt-and-transaction-data[Receipt and transaction data] --> policy-agent
  expense-policy-document[Expense policy document] --> policy-agent
  hris-fields[HRIS fields] --> policy-agent
  policy-agent --> accounting-code-agent
  policy-agent --> human-reviewer[Human reviewer]
  human-reviewer --> eval-dataset[Eval dataset]
  policy-agent --> eval-dataset
  clockwork-labeling-tool[Clockwork labeling tool] --> eval-dataset
  eval-dataset --> ci-eval-runner[CI eval runner]
  ci-eval-runner --> applied-ai-service[Applied AI service]
  applied-ai-service --> model-provider-layer[Model provider layer]
  applied-ai-service --> batch-workflow-handler[Batch workflow handler]
  applied-ai-service --> cost-tracing[Cost tracing]
  applied-ai-service --> tool-catalog
  ramp-inspect[Ramp Inspect] --> modal-sandbox[Modal sandbox]
  ramp-inspect --> github-branch[GitHub branch]
  ramp-inspect --> context-integrations[Context integrations]
  ramp-inspect --> ci-test-suite[CI test suite]
  human-collaborator[Human collaborator] --> ramp-inspect
  github-branch --> ci-test-suite

Components

Data flow

A user interacts through Omnichat or a product workflow. The agent framework resolves entities, selects tools, and may execute deterministic playbooks. For policy review, receipt images, transaction data, policy text, HRIS fields, and tool outputs flow into the policy agent; the agent writes approval/rejection decisions, reasoning, and accounting handoffs, escalating to a human when needed. Weekly labeling sessions create eval data, CI evals check changes, and the applied-AI service supplies model access, structured outputs, batch processing, and cost tracing. In parallel, Ramp Inspect receives work from UI/API/Slack, spins up a sandbox, pulls company context, creates a GitHub branch, runs tests, and collaborates with humans before production merge.

Why this architecture

Ramp consolidated around shared orchestration because decentralized teams had created overlapping agent systems. A single agent framework with a large skill/tool catalog lets teams reuse capabilities, Omnichat provides one user-facing entry point, playbooks preserve determinism where workflows are known, evals and labeling protect sensitive policy decisions, and the applied-AI service prevents every team from solving provider APIs, batch jobs, model switching, and cost tracing on its own.

Models used: OpenAI models · Anthropic Claude Opus · GPT 5.3 · Opus 4.6 · Gemini 3 Pro · Vision models · LLMs used by Ramp agents

Scale

• Ramp serves more than 50,000 customers.
  “number one finance platform for modern businesses with 50,000 plus customers”transcript, stated
• Ramp began with one-shot AI tasks about three years earlier.
  “Probably by now about 3 years ago, we started doing this one-shot things with AI.”transcript, stated
• Ramp previously had about five separate conversational UXs before consolidating into Omnichat.
  “at the end of last year we had about five different conversational UXs.”transcript, stated
• A product manager created about 20 tools without engineer involvement.
  “one product manager Vibe coded about 20 tools so engineers are no longer needed to build these tools.”transcript, stated
• Policy-agent use cases can involve hundreds or thousands of receipts.
  “finance teams are looking at receipts like this basically every day, and maybe they might have hundreds or thousands of these.”transcript, stated
• The team started policy-agent evals with five examples rather than waiting for a thousand-point dataset.
  “You don't need a full data set of a thousand data points that you're testing against every iteration. We started with five.”transcript, stated
• The internal tool catalog had many hundreds of tools and was expected to grow to multiple thousands.
  “We're up to like many hundreds of these tools today”transcript, stated

  “this could be like multiple thousands over time.”transcript, stated
• Ramp Inspect was responsible for more than 50% of PRs merged to production.
  “Ramp Inspect is responsible for over 50% of PRs that we merge to production.”transcript, stated
• Ramp Inspect has access to more than 150,000 tests.
  “it has access to the 150 plus thousand tests that we have.”transcript, stated

Alternatives considered (roads not taken)

Build thousands of separate agents

Rejected because: Ramp found duplicate implementations and decided the better abstraction was a single framework with many skills.

Hardcode incremental expense-policy rules

Rejected because: The team saw natural-language policy itself as the rule source rather than adding ever more deterministic rules.

Launch fully autonomous policy actions immediately

Rejected because: Trust had to build through suggestions before customers chose auto-approval thresholds.

Use an external labeling tool

Rejected because: Available tools were either too use-case-specific or too general, so Ramp built a low-maintenance Streamlit app.

Let downstream teams integrate model providers, batching, and cost controls independently

Rejected because: Ramp centralized these platform concerns so product teams could focus on customer value.

Patterns

multi-agent-orchestration (agent-architecture)

Ramp consolidated many product agents into a shared framework where Omnichat, policy agent, accounting code agent, playbooks, and internal tools compose through a common orchestration layer.

tool-use-orchestration (agent-architecture)

Agents use a shared catalog of internal tools for policy snippets, per diem rates, recent transactions, HRIS, ERP, read replicas, DataDog, and other systems.

structured-output-contract (platform-infrastructure)

Ramp's applied-AI service standardizes structured output and provider SDK behavior so teams can switch models without rebuilding call sites.

human-in-the-loop-gate (risk-control)

Policy decisions can involve a human reviewer, and customer autonomy ramps from suggestions to self-selected auto-approvals.

eval-driven-development (evaluation)

Ramp uses early, easy-to-run offline evals, weekly labeled ground truth, CI checks, and online health metrics to catch regressions from context, tools, prompts, or model changes.

observability-tracing (operations)

Ramp tracks model/tool costs by team and product and uses auditability of agent inputs and outputs to reason about black-box behavior.

cost-aware-routing (production-optimization)

The applied-AI surface compares model performance against cost and lets teams switch providers through config instead of scattered SDK work.

batch-offline-processing (platform-infrastructure)

The applied-AI service centralizes batch processing and workflow handling for evals, bulk documents, data analysis, rate limits, and online/offline jobs.

Tradeoffs

Consolidate agent architecture

Chose One shared agent framework with many skills and tools over Thousands of specialized, siloed agents.

Rationale: The decentralized approach produced duplicate implementations; a shared framework makes capabilities reusable across jobs to be done.

Start policy automation with narrow low-risk cases

Chose Coffee-with-colleague transactions and suggestions over Automating all finance reviews on day one.

Rationale: The team believed AI products could not be one-shotted and needed a simple wedge for iteration and trust building.

Use expense policy as executable business logic

Chose Natural-language policy documents interpreted by the agent over Incremental deterministic rule growth.

Rationale: The policy document already expresses what customers want approved or rejected; making it the rule source lets finance teams improve behavior by editing policy language.

Accept more autonomy with stronger auditability

Chose Full agentic workflow with read/write tools over A simpler chain of well-defined LLM calls only.

Rationale: Capability and autonomy increased, but traceability decreased, so the architecture needed input/output auditability.

Build an internal labeling tool

Chose Clockwork on Streamlit over Weeks of vendor evaluation for labeling tools.

Rationale: Ramp wanted a low-maintenance, low-risk, quickly modifiable tool that non-engineers could personalize.

Centralize model-provider and workflow plumbing

Chose Applied AI service with consistent APIs, batch handling, cost tracing, and one-line model switches over Product teams managing provider SDK churn, batching, rate limits, and scattered call sites.

Rationale: The platform hides fast-changing provider APIs and lets teams compare performance/cost or switch models through configuration.

Gotchas (what bit them)

Decentralized agent experimentation created duplicate systems.

Root cause: Individual teams built separate implementations for similar synchronous and background-agent tasks.

Resolution: Consolidate around a shared agent framework and skill/tool catalog.

Policy-agent failures were often context failures, not model failures.

Root cause: The agent lacked business context such as employee role, title, level, receipt details, and HRIS fields.

Resolution: Use live internal data to discover missing context, then extract more receipt information and pull HRIS fields.

More capable agentic workflows became harder to explain.

Root cause: As autonomy and tool use increased, the system's behavior became a larger black box.

Resolution: Assume inputs and outputs are the stable audit boundary and build strong auditability from the beginning.

User behavior could not be treated as ground truth.

Root cause: Users sometimes approved or rejected expenses incorrectly because they did not know policy, were lazy, or trusted employees too much.

Resolution: Create an explicit correctness definition through cross-functional labeling and a ground-truth dataset.

Helpful-looking context and tools can create hidden regressions.

Root cause: Added context, tool instructions, or confusing docstrings can have unintended negative effects on LLM/agent behavior.

Resolution: Run evals early and make results easy enough to inspect in CI.

Coding agents can produce larger mistakes faster.

Root cause: Raw coding speed does not replace product judgment, context, and the ability to see around corners.

Resolution: Design agents around collaboration, context access, tests, and human judgment rather than treating coding as the whole job.

Evaluation

Ramp evaluates agent behavior through weekly cross-functional labeling, a ground-truth dataset, early offline evals that can start with only a few examples, easy-to-run command/CI checks, online health metrics such as unsure-decision rates, and benchmark runs for model changes. The key philosophy is to make evals early, understandable, and cheap enough to catch regressions from context, tools, prompts, docstrings, and new frontier models.

Metrics: Ground-truth label agreement · Offline eval pass/fail · CI eval results · Online unsure-decision rate · Model-change benchmark results · Cost by team and product · Model performance-for-cost · PR share through Ramp Inspect · Test pass/fail across the CI suite

Outcomes

• Ramp consolidated from multiple conversational UXs and duplicate agent implementations toward Omnichat and a shared agent framework.
• The policy agent became available across the Ramp platform.
• Design partners, including Fortune 500 customers, moved from suggestions toward auto-approval for low-risk cases such as expenses under $200.
• The shared tool catalog reached many hundreds of tools with a path to multiple thousands.
• Ramp Inspect became responsible for over 50% of production PRs merged weekly/monthly as described in the talk.
• Ramp Inspect was adopted beyond engineering by product, design, risk, legal, corporate finance, marketing, and CX teams.
• The internal coding-agent environment supports sandboxes, GitHub branches, company context, Chrome DevTools/MCP, and access to 150K+ tests.

The transcript reports 50,000-plus customers, about five prior conversational UXs, one PM creating about 20 tools, hundreds-to-thousands of tool-catalog entries, weekly labeling with 100 data-point homework, initial evals starting with five examples, auto-approval thresholds such as under $200, Ramp Inspect producing over 50% of production PRs, and access to 150K+ tests.