> ## Documentation Index
> Fetch the complete documentation index at: https://parabola.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# How we deploy: bottoms up and top down
> How Parabola's Applied AI team helps finance and operations teams go from a first Flow to thousands: process owners capture the work, and we connect it into end-to-end processes.
Most enterprise AI deployment follows the forward deployed engineer model: a vendor sends engineers into the customer, they work from an executive mandate, and they build a system for the organization. It is a proven way to deliver a few large, well-defined systems.
Parabola's Applied AI team is forward deployed too, but the hard part of becoming AI-native is the long tail, and the long tail does not deploy from the top alone. Ours is bottoms up and top down: the people closest to each process capture the work as Flows, and our team connects what they build into end-to-end processes.
## Why the long tail needs a different model
The long tail is the thousands of company-specific processes that collectively run finance and operations: reconciliations, accruals, audits, matching rules, exception reviews, handoffs. It is not the unimportant edge of the business. It is most of the work.
* **Work is scattered.** ERP, warehouse, spreadsheet, PDF, email, partner portal. Every process spans a different mix of systems and teams.
* **Logic is not documented.** What to match, what to ignore, what to override, and what to investigate lives in spreadsheets, workarounds, and the team's heads.
* **Processes keep changing.** New customers, vendors, exceptions, and policies keep the work in flux, and the subject-matter experts need to own the changes.
A top-down build handles this with requirements, and requirements handoffs separate the implementation from the people who understand the process and must keep changing it. That works for the first system. It does not scale to the next thousand.
## Bottoms up: process owners capture the work
The AP analyst, the inventory planner, and the freight coordinator are not stakeholders we interview. They are the build team, because they hold the context no requirements document captures.
Working alongside an Automation Engineer, they build the system while doing the work:
* **Capture.** Talk through the process on real data. Prowork generates the code underneath and records each source, rule, calculation, and exception as a visible, editable step.
* **Validate.** Run every step against live data, trace results through their inputs and logic, and add the edge cases only the team knows until the Flow holds up.
* **Run.** Deploy the Flow as a managed agent: on demand, on a schedule, or when new data arrives, with permissions, monitoring, and lineage built in.
* **Improve.** Real runs expose the next exception. The team fixes it directly in the Flow, and changes it again when the policy changes next quarter.
Our engineers bring patterns from similar businesses and adapt them to your systems, rules, and exceptions. They do not become the owners. When the engagement moves on, the controller's team owns the accrual Flow, can trace any number in it, and changes it themselves.
## Top down: Applied AI connects the pieces
Bottoms up produces a lot of Flows, each correct on its own and each solving one piece of the long tail. Left there, they stay siloed: the three-way match in AP, cash application in treasury, the aging review in collections. Nobody inside one function has the vantage point to see how they fit together. That is the Applied AI team's job.
It starts with your executives and IT: which outcomes matter, to whom, and why. A faster close. Better working capital. Fewer stockouts. Fewer exceptions that reach a customer. That decides where to start, which Flows belong together, and what the governed environment needs to look like.
Then Automation Engineers do the work individual teams cannot do from inside their own function:
* **Stitch.** Connect Flows across AP, AR, treasury, and operations so the output of one is the input of the next, and order-to-cash or procure-to-pay runs as one visible, traceable process instead of a chain of handoffs.
* **Improve end to end.** Remove the manual step between two Flows that could be a trigger, standardize the exception handled three different ways, retire the report nobody reads because the fix moved upstream.
* **Roll up.** Tie every Flow to a metric someone at the top owns, so leadership sees a connected system with logic anyone can inspect, not a collection of automations nobody can account for.
Process owners capture the work. Functional leaders scale it. IT governs the environment. Executives realize the leverage. Applied AI is how those four move together.
| | Traditional forward deployment | Parabola's Applied AI |
| -------------------------- | ------------------------------ | ----------------------------------------------------------------------------- |
| Who builds | Vendor engineers | Process owners, with an Automation Engineer beside them |
| Where the logic comes from | Requirements and interviews | The people doing the work, on live data |
| What gets built | A system for the organization | Visible, code-backed Flows the team owns, connected into end-to-end processes |
| Who owns changes | The vendor, through a ticket | The process owner, directly in the Flow |
| How it scales | Another engagement | Teams keep capturing; Applied AI keeps connecting and improving |
## What an engagement looks like
Discovery with leadership, IT, and the teams doing the work. We leave with the first one to three processes, their data sources, their owners, and how success will be measured.
Onsite workshops or hackathons and focused sprints with the people closest to the work. They capture their processes as Flows on connected, real data and validate them live. The workshop is the enablement: teams do not attend training and then go build. They build, and that is the training.
Validated Flows run as managed agents. Internal champions carry the practice to their teams. The Applied AI team connects what each team built into programs such as order-to-cash, procure-to-pay, close, and inventory, and improves them as one system.
Bring one of your highest-friction reconciliations, audits, or exception processes. We will map it together.