From AI Coding to Business Agents: Transferring Engineering Practices with Business Context

The author describes using large models to assist development while integrating an Agent with a self-built ontology semantic platform, prompting the question: how much of the experience accumulated in AI programming can be carried into business systems? A recent InfoQ article on traditional enterprise AI transformation raised the same direction, but the specifics of what to retain and what to supplement remain unclear.

Experience Must Be Captured as Engineering Artifacts

Developing a moderately complex feature with an Agent reveals common failures: vague task descriptions lead the Agent to invent assumptions; chaotic material versions cause it to modify code against outdated designs; lacking acceptance criteria yields an unsubstantiated "done." The author therefore emphasizes design rationale, role responsibilities, and verification results during development — developers flag design gaps for architects to fill; testers check implementations against designs and feed back deviations; tools assist execution while humans confirm goals and key trade-offs.

To let other departments reuse this experience, concrete engineering artifacts must be produced: task templates, controlled tool entry points, business evaluation cases, and handover flows. These artifacts must hook into the execution process — templates read at task start, permissions checked on tool calls, validation run on output, exceptions handed over with records. Merely writing experience into a shared document leaves business people to figure it out themselves.

However, method transferability does not mean swapping prompts works directly. Developers know code repositories, files, and interfaces, but may not know whether "order complete" in business parlance means shipped, delivered, or settled.

A Small Task: Organizing After-Sales Ticket Materials

A hypothetical case illustrates the gap. The business wants an Agent to, when an after-sales agent opens a ticket, organize product info, purchase records, and applicable policies, list missing materials, and generate a pending-review processing summary. Phase one only does material organization and summary — no compensation promises, no direct refund operations. The after-sales person reviews and continues in the existing ticket workflow.

If the AI programming workflow is naively reused, developers might list steps: read ticket, query order, retrieve policy, generate summary, check result. But connecting to real systems surfaces concrete problems: can the product name on the ticket map to the SKU in the order? Which purchase record should a replacement product link to? Do historical handling methods still comply with current policies? Can warranty eligibility be judged without a purchase receipt?

These issues affect not fluency but whether downstream people can act on the output. Even if every API call succeeds, materials may be linked to the wrong records or policies misapplied.

After Tools Are Connected, Business Conventions Must Be Filled In

The runtime can provide tool calls, execution logs, and error feedback, but cannot know all enterprise business conventions from interface names alone. At least three things need joint confirmation by business and R&D:

Objects must be matchable. What identifiers link tickets, customers, orders, and product instances? Which cases yield only candidate matches? Similar product names are search clues, not proof of identity.

Rules must have applicability conditions. Policies have content plus effective times, product scopes, regions, and exceptions. Historical tickets provide reference but cannot automatically become current handling rules.

Outputs must have explicit purposes. "Organize materials," "give suggestions," "form decisions," "execute operations" map to different responsibilities and authorizations. A generated summary only means materials are organized to this point; it must not be mistaken for an approval in the workflow.

These conventions can live in interface specs, rule tables, and a few confirmed cases. The key is making them accessible to the Agent, checkable by code, and correctable by business people. If business people themselves lack a consistent interpretation, the platform should surface the conflict for authorized decision-makers — dumping conflicting materials into the model will not auto-produce an organizationally accepted answer.

Why the Author Combines Agent with an Ontology Semantic Platform

The author currently extends an Agent based on DeepSeek Harness and integrates it with an ontology semantic platform, aiming to make business objects, relationships, and rules available as execution-time grounds. The ontology platform straightforwardly means: organize definitions of what objects exist in the business, their relationships, and what their states mean, and connect them to actual data and services.

In the after-sales case, the runtime organizes queries and material assembly; the semantic layer supplies business meaning and mappings among tickets, products, and records; the original business systems persist and process actual state. Correctness of linkages still requires business confirmation and data validation; access and operation permissions are enforced by the respective systems.

A full ontology need not be built for every small assistant. When a single system has simple objects and stable interface semantics, clear interface contracts and rule tables may suffice. Only when cross-system object linking, terminology differences, or rule reuse repeatedly cause problems does further investment in a semantic platform become worth evaluating. The author notes this is the current building direction, not that the after-sales case is already deployed on the platform.

Reuse Verification Methods, Redefine Completion Criteria

Build, test, and code review in AI programming provide repeatable verification grounds, but they do not cover all needs. Business agents likewise need verification, just with different objects. Whether an after-sales summary is acceptable can be broken into checkable questions:

Material linkage — Result to confirm: Correct order and product records used for the ticket. Evidence to retain: Object IDs, query conditions, source records.

Policy applicability — Result to confirm: Cited policy matches current task conditions. Evidence to retain: Policy version, effective time, applicability conditions.

Content completeness — Result to confirm: Missing and conflicting materials explicitly flagged. Evidence to retain: Required material list, missing items, conflict sources.

Conclusion grounding — Result to confirm: Key statements traceable to materials. Evidence to retain: Statement-to-source mapping, manual review records.

Some checks can be automated; others still need business judgment. Citing a document requires verifying the cited content actually supports the conclusion; correct output format does not substitute for content validation.

The replacement-product scenario can be walked through once. Suppose the Agent finds two candidate purchase records but lacks the before/after product mapping. The summary should list candidate records, their sources, and the missing linkage, marking warranty eligibility as pending verification. After the after-sales person confirms the mapping via replacement records, the Agent reassembles the summary on the confirmed materials for human review. The completion condition here is: material linkages clear, sources traceable, unresolved issues listed.

This confirmation can also yield a pending improvement suggestion. The business owner judges whether it is a one-off supplement or requires a general rule enhancement; R&D then augments query logic or task conventions and adds a regression case. The case checks both that evidence gaps are reported and that, once evidence is supplied, correct linkage occurs, while also regressing ordinary tickets to ensure existing behavior is not broken. One manual fix does not automatically become a universal rule for all tickets.

Future model, tool, or policy changes can re-run these cases to detect regressions. If business tasks later involve writes, separate verification of authorization, request results, and final business state is needed — the summary task's completion standard cannot be reused.

Do One Task Well First, Then Decide What Goes into the Platform

R&D teams can build platforms, but before the first business scenario is validated, premature unified platform design may just solidify the team's own assumptions. For the after-sales material organization task, the author prefers to first involve business people to scope the task, connect necessary data and policy sources, and run one end-to-end flow from material preparation to manual review.

Then observe: did material lookup time decrease? Did review and rework increase? Was work shifted to other roles? Comparison must use similarly difficult tasks, counting failures and rework, not just summary generation speed.

Existing identity access, execution logs, version management, and evaluation entry points can be reused from the first scenario. Missing necessary capabilities should be filled per task, not deferred until multiple scenarios appear.

What needs gradual validation is whether new abstractions are worth sharing. For example, can the material linkage flow in the after-sales task serve other tasks? Compare whether objects, evidence requirements, and exception handling are compatible. Different departments' business judgment and authorization rules should retain their own owners and applicability conditions. The basis for platformization is genuinely reduced duplicate construction and maintenance burden.

R&D can lead establishing this engineering mechanism, but business owners must still confirm whether the task is worth doing, the grounds are correct, and the outcome improves. Enterprises with weaker R&D can obtain engineering support from external teams — "starting from R&D" is not a mandatory fixed path for all companies.

Summary

The pits R&D teams have stepped in during AI programming can indeed help business avoid some detours. But for experience to create organizational value, it must be landed as tools business people can use, grounds they can verify, and processes where someone handles problems when they arise.

For the author, the most worthwhile continued investment in moving from AI programming to building business agents lies in this connection: letting existing engineering capabilities catch concrete business, and letting execution results return to business facts for verification.

Reference

InfoQ, Yu Xi: "The Shortest Path for Traditional Enterprise AI Transformation Lies in the R&D Department," 2026-09-07. https://www.infoq.cn/article/jrEuCFhtpA9LmGX60R1H

This article takes the R&D experience migration question raised in that piece as its starting point. The after-sales task is a hypothetical case; the building methods and verification approaches are personal analysis and do not use the reported enterprise efficiency numbers as proof of effect.