In this field note
The short answer
An AI assistant becomes meaningfully connected to business software when it can discover one well-described capability, send valid inputs, receive current structured data, and explain the result without pretending it owns the underlying record. The valuable design object is not the chat window. It is the small contract between the person’s question and the system that knows the answer.
The day the assistant stops guessing
Ask an ordinary chatbot, “Which open orders are likely to miss Friday’s ship date?” and it can offer sensible advice about schedules, materials, and bottlenecks. It cannot know which orders are open right now unless an application gives it a legitimate path to current records.
Now imagine the same question inside an assistant connected to a narrowly defined tool called list_at_risk_orders. The tool belongs to the business application. It describes the dates it accepts, the fields it returns, and the records the current user may see. The assistant decides that the tool fits the question, supplies Friday’s date, and turns the returned rows into a readable answer.
That is the practical promise behind an AI business software integration: the model does not suddenly “know the business.” It gains a controlled way to ask the software that does.
Open the wire: one question, one capability
The trace below is illustrative. Example Fabrication, the order numbers, dates, blockers, tool, and results are fictional. It is not a customer system or a reported QC Devworks test.
-
The application exposes a tool
- Name
list_at_ risk_ orders - Description
- Return open orders with a promised ship date on or before the supplied date and a current blocking condition.
- Inputs
ship_byas an ISO date; optionallimitfrom 1 to 20.- Returns
- Order ID, promised date, blocker, last-updated time, and an authorized record link.
-
The assistant makes one call
- User request
- “Which open orders are likely to miss Friday, September 18, and what is blocking each one?”
- Arguments
ship_by: 2026-09-18;limit: 5.- Operation
- Read-only. It asks for current information; it does not move a date, notify a customer, or update an order.
-
The system returns a structured result
- Order 10482
- Promised September 17; powder-coat slot moved; updated 7:42 a.m.
- Order 10507
- Promised September 18; two inspected parts remain on hold; updated 7:51 a.m.
- Source
- Each row carries a link back to the authorized order record and the time the risk view was calculated.
The assistant can now answer with the two orders, name each blocker, state when the data was updated, and link the reader to the source record. It can also say that no other matching rows were returned. It should not invent a root cause, a revised ship date, or a customer’s preferred response, because those facts were never in the result.
The assistant does not become the order system
Three pieces are doing different jobs.
The business software owns the records, permissions, and calculation that decide whether an order is at risk. The tool server turns one approved capability into a name, a description, an input shape, and a result shape. The AI application decides when the capability matches the person’s request, supplies arguments, and communicates what came back.
The current Model Context Protocol specification makes that separation visible. A client can discover tools with tools/list, call one with tools/call, and receive structured content that conforms to an output schema. The authorized tool set may differ by the credentials on the request. Those are protocol mechanics, not business meaning: a developer still has to decide what “at risk” means, which records a user may see, and how freshness appears in the result.
MCP is one way to express this contract. A conventional API or another function-calling layer can implement the same product idea. The important part is that the capability is explicit enough for software to validate and small enough for a person to understand.
The small contract is the real product decision
A vague tool called query_database pushes the hardest questions onto the model: which tables matter, how records join, whether a status is current, and what the user is allowed to retrieve. It also makes the assistant’s failure difficult to explain.
A business-shaped capability carries more meaning. list_at_risk_orders can use the same definition of open, promised, blocked, and visible that the operational product uses. It can reject an invalid date, cap the number of rows, return a calculation timestamp, and omit records outside the caller’s scope. The model is no longer improvising business logic from column names.
A useful answer is not permission to change the record
The example tool can read order risk. It cannot reschedule an order. That is not a temporary limitation hidden behind the interface; it is part of the contract.
If the product later needs a change capability, it should be a different operation with different inputs and consequences—perhaps propose_ship_date_change, which prepares a proposed date and reason without committing it. The application can then place the appropriate user decision around that action. The MCP specification recommends clear tool visibility and human control, while requiring servers to validate inputs and enforce access controls.
This distinction keeps the conversation honest. “Show me what is at risk” and “change what the customer was promised” may appear in the same chat, but they are not the same software permission.
Where this becomes better than a search box
If a person already knows order 10482, an ordinary order search may be faster. AI becomes useful when the request combines intent with current context: “Show the orders due before Friday that are blocked outside our building, summarize the common cause, and give me the links.”
The assistant can translate that request into one or more supported calls, keep the result fields intact, and adapt the explanation to the reader. A production manager may want blocker and operation. An account owner may want promise date and customer-impact notes. Both views can start from the same authorized records without copying an entire database into a prompt.
That possibility fits the kind of connected operational product QC Devworks describes in its AI Agents & Automation and Application Engineering work. The public IntelliSee case study also shows why operational software spans several users and views. This example does not claim IntelliSee uses the fictional order tool; it shows a general interaction that connected products can support.
The trace also reveals the failure modes
If the returned rows lack an update time, the assistant cannot tell whether “current” means seconds or hours ago. If the result omits record links, a person cannot inspect the source. If the tool silently defines Friday in a different time zone, the answer may be internally valid and operationally wrong. If the description promises open orders while the implementation includes canceled work, the model cannot repair the contradiction.
Structured output prevents some shape errors; it does not guarantee truthful data or good business semantics. The MCP specification assigns input validation, access control, rate limiting, output sanitation, and result validation to the surrounding clients and servers. The tool contract makes those responsibilities inspectable. It does not make them disappear.
Start with one question worth answering from the system of record
The strongest first capability is usually not “let the AI use everything.” It is one recurring question whose answer currently requires a person to search, join context, and explain what they found.
Write the question in the language the team already uses. Identify the software that owns each fact. Decide what a current, useful result must contain. Then expose the smallest read-only capability that can return those facts with timestamps and source links. When the assistant answers, a person should be able to trace every important statement back to the result.
That is enough to learn whether the interaction is genuinely useful before adding broader access or consequential actions.
Sources
Bring one expensive question
If a useful answer is trapped behind three screens and one person’s memory, bring QC Devworks the question, the source system, and an example of the answer your team trusts. We can help shape the smallest capability that lets software answer it clearly—before anyone talks about an all-purpose agent.