# AI Agents in Production: Automating Sales Follow-Up, Contract Review, and Financial Reporting

The Paradigm Shift: From Chat Assistant to Task Executor

Over the past two years, the typical form of a large language model in the enterprise has been the chat assistant: employees ask questions, the model answers, and the human remains the one executing the workflow. Once models gained the ability to call tools (Function Calling / Tool Use), retain long-horizon memory, and plan across multiple steps, their role shifted from offering advice to getting the job done. This jump from conversation to a closed task loop is the precondition for an agent to genuinely take over business work.

Three conditions generally determine whether a task can be handed to an agent:

1. The rules are digitizable: inputs and outputs can be expressed as structured data, and judgment criteria can be written as executable logic or as constraints the model can understand.
2. The process is decomposable: the task breaks into sub-steps that can be verified independently, rather than a one-shot black box.
3. The result is verifiable: the output has an objective way to be checked (format, formulas, a rule base, a receipt from an external system), which makes automatic error correction possible.

Sales follow-up, contract review, and financial reporting satisfy all three at once. That is the fundamental reason they became the first enterprise-grade agent deployments.

Why Sales, Contracts, and Finance

On the surface these three areas belong to three different departments: marketing, legal, and finance. From a technical standpoint, however, they share the same underlying pattern: unstructured input → semantic understanding → rule-based judgment → structured output → write-back to systems.

• Sales follow-up: customer emails, chat logs, call notes → extract intent and key information → decide on a follow-up strategy → update the CRM record and generate the next action.
• Contract review: PDF/Word contracts → understand clause by clause → compare against a risk rule base → output review comments and suggested revisions.
• Financial reporting: raw data from business systems → classify and aggregate → apply accounting rules and validation formulas → generate reports and flag anomalies.

Once you recognize that shared pattern, a single architecture can support all three, however different they look on the surface.

Core Agent Architecture: Sense, Decide, Act, Feedback

The minimum viable architecture of an enterprise-grade agent has four stages:

┌────────────┐   ┌────────────┐   ┌────────────┐   ┌────────────┐
│  Perception│──▶│ Decision   │──▶│  Execution │──▶│  Feedback  │
│ Input      │   │ Plan/Reason│   │ Tool calls │   │ Validation │
│ understand.│   │            │   │            │   │            │
└────────────┘   └────────────┘   └────────────┘   └────────────┘
      ▲                                                  │
      └────────────────── iterate / retry ◀──────────────┘

The perception layer turns multimodal inputs such as emails, contract documents, and business data into context the model can process. It typically involves document parsing, OCR, chunking, and vectorization.

The decision layer is the brain of the agent. It decomposes the overall task into a sequence of sub-tasks and decides which tool to call at each step. In practice, a system prompt constrains the role and the goal, and tool schemas tell the model what capabilities it has.

The execution layer interacts with external systems through structured tool interfaces. The key convention here: the model only emits a call intent, and deterministic code performs the actual execution. For example:

{
  "tool": "query_customer_order",
  "arguments": {
    "customer_id": "C-10086",
    "date_range": "2026-09-01~2026-09-30"
  }
}

The feedback layer validates the result: do the amounts balance, are all required fields present, did the external system return a success receipt? When validation fails, the agent carries the error back to the decision layer and retries, forming a self-healing loop.

This split between the model reasoning and the code executing is the core principle for reliability: never let a large language model directly execute operations with side effects. Instead, have it generate controlled, structured instructions.

Use Case 1: Closing the Loop on Sales Follow-Up

Sales follow-up is fundamentally about contacting the right person with the right content at the right time. The value of an agent here is that it aggregates signals scattered across emails and chat records.

A typical workflow:

1. Collect signals: periodically pull the latest emails, tickets, and meeting notes for each customer.
2. Recognize intent: the model judges which stage the customer is at (inquiry, comparison shopping, hesitation, closing) and extracts key entities (budget, decision maker, competitors).
3. Generate strategy: produce a draft follow-up script and suggested next actions based on the stage.
4. Human confirmation: actions on high-value customers require human review before sending, to avoid mis-sends.
5. Write back results: store the follow-up outcome as structured data in the CRM and update the next follow-up reminder.

One engineering detail deserves emphasis: sales scenarios are highly sensitive to the asymmetric cost of mistakes. Missing a customer costs an opportunity, but a wrong commitment (quoting a discount on its own, for instance) can trigger a commercial dispute. Script generation should therefore be limited to drafts, and any output involving price or contract terms must go through human confirmation. This belongs in the system prompt as a hard constraint.

Use Case 2: Structured Understanding in Contract Review

Contract review is the scenario that best showcases long-context capability in LLMs, and also one of the riskiest applications. The reliable approach is to convert free-form question answering into fill-in-the-blank structured extraction.

Start by constraining the model’s output with a fixed review checklist (a schema) rather than letting it speak in generalities:

review_schema = {
    "contract_type": "string, contract type",
    "parties": ["Party A", "Party B"],
    "amount": "numeric value + currency",
    "payment_terms": "payment milestones and proportions",
    "liability_cap": "liability cap clause",
    "termination": "termination conditions",
    "risk_items": [
        {"clause": "original clause text", "risk_level": "high / medium / low", "reason": "risk explanation"}
    ]
}

The model’s job is to fill in this structure field by field and label a risk level for each entry in risk_items. The validation layer then does two things:

• Completeness check: are required fields empty, does the amount match its written-out form?
• Rule comparison: compare the extracted result against the enterprise risk rule base (for example, “the payment period must not exceed 90 days” or “the penalty cap must not exceed 30% of the contract value”). Any match raises an alert.

With this design, the model’s comprehension is confined to a verifiable frame, and every risk item can be traced back to the original contract text, which makes review by legal staff straightforward. As in the other scenarios, the agent only produces review comments and does not make legal decisions on a person’s behalf. Final sign-off still requires legal approval.

Use Case 3: Financial Report Generation and Validation

Financial reporting has one major advantage: strong objective validation standards, including accounting identities, cross-referencing relationships, and formula constraints. This actually makes agents most reliable in this domain, because “right or wrong” is something a program can determine.

The flow abstracts to:

Raw business data → Classification mapping → Aggregation → Formula validation → Report generation → Anomaly attribution

The model handles the semantic tasks of classification mapping and anomaly explanation, while the calculation itself should be delegated to deterministic code:

# Calculation is done by code; the model does not perform numeric operations
total_debit = sum(entry.amount for entry in ledger if entry.side == "debit")
total_credit = sum(entry.amount for entry in ledger if entry.side == "credit")
assert abs(total_debit - total_credit) < 0.01, "Debits and credits do not balance; manual review required"

When validation detects that an account balance has fluctuated abnormally, the agent pulls the underlying detail data to perform attribution analysis and produces a readable narrative of the variance. Splitting the work between numbers from code and explanation from the model preserves accuracy while keeping the model’s expressive strength.

Key Engineering Challenges: Reliability, Least Privilege, and Security

To make an agent actually take over work rather than remain a demo, three classes of engineering problems must be solved.

1. Reliability and observability

The decision chain of every agent should be fully recorded: what went in, which tools were called, what each step returned, and what came out. This trace data belongs in a logging service and monitoring/alerting system, so failures can be located and failure rates analyzed. Human-in-the-loop is the standard production strategy, with mandatory human confirmation for high-risk actions.

2. Least privilege

An agent connects to real business systems such as CRM, ERP, and finance platforms, so it must follow the principle of least privilege: grant each tool interface only the minimum data access needed to complete its task. Read and write operations should be separated, and sensitive data should be masked before it enters the model context.

3. Data security and compliance

Enterprise data often contains customer privacy and trade secrets, so the architecture must state clearly from the start which data may enter the model context and which must stay local. Where data cannot leave its environment, inference can be run in the company’s own infrastructure so data never crosses the enterprise boundary. Credentials and keys should be managed by a secrets management service and must never be hard-coded into prompts or source code.

On the cloud, these capabilities usually map onto a handful of general service categories: object storage for contract and report files, message queues to decouple asynchronous tasks, a container platform to host the agent runtime, logging and monitoring/alerting for observability, and key management to protect credentials. On Baidu AI Cloud, for example, these general capabilities can be composed into a complete enterprise-grade agent foundation, so developers do not have to build the entire infrastructure stack themselves.

Rollout Recommendations

Bringing agents into enterprise workflows calls for a gradual path, from low risk to high risk and from assisting to taking over:

1. Start with scenarios that have clear validation standards. Tasks such as financial reporting and reconciliation, where correctness can be judged objectively, carry the least risk and make a good starting point.
2. Keep the division between model reasoning and code execution. All side-effecting operations go through controlled tool interfaces; the model never executes them directly.
3. Enable human confirmation by default. Until accuracy and trust are established, a person should always retain the final decision.
4. Build complete tracing and evaluation. Use real failure cases to keep iterating on prompts, tool descriptions, and validation rules.
5. Put permissions and compliance in front of the work, not after it.

An agent taking over sales, contracts, and finance is not about replacing people. It frees them from repetitive information shuffling and first-pass screening, so professional judgment can concentrate where experience and accountability actually matter. For developers, the real challenge is not making a model that can chat, but building a task execution system that is reliable, auditable, and rollback-capable. That is the real dividing line between an enterprise-grade agent that demos and one that runs in production.