"I want to exchange the product I ordered." AI can prepare a polite response to a request like this. It can check the exchange conditions and list the work a person needs to do. But in many companies, the final step still belongs to a human: opening the admin screen, finding the order, and changing the information.

This is an easy boundary to miss when thinking about AI adoption. The customer does not only want to know how an exchange works. They want the exchange to actually happen. Between writing the answer and processing the request, there is still the work of operating the system.

If we want AI to handle that much, we need to think not only about the model's intelligence, but also about what our internal systems make available. APIs sit at the center of that question.

When the user of a system changes

Until now, when building business systems, we have usually imagined people operating screens. We make information easy to find, reduce the amount of input, and place buttons where they are hard to press by mistake. Improving the UI has been directly connected to making work easier.

With that assumption, a system can feel complete once the work can be done from the screen. Interfaces that let other software call the same functions can be postponed until integration becomes necessary.

But if AI is going to handle daily searching, input, and updates, the way systems are used changes. A screen that is convenient for humans is not enough if AI has no route to fetch the required information or execute the required operation.

An API, or application programming interface, is a doorway for software to exchange functions and data. A system can receive an order number and return order details, or receive a change request and update a shipping address. It lets another piece of software call operations that a person would otherwise perform on a screen.

Put a little boldly, APIs are the UI for AI. Just as we have prepared entry points that are easy for humans to use, we now need entry points that let AI do work. In that sense, APIs are moving from optional future integration features to infrastructure for delegating work to AI now.

Humans will still need UI to understand situations, make decisions, and handle exceptions. But for work we want to hand over to AI, we should ask who will perform the operation before designing the next input screen. First prepare the API, then design the UI needed for human confirmation and exception handling. It is time to reorganize development priorities around that order.

APIs support UI, CLI, and MCP

The value of preparing APIs is not limited to making one AI feature work. It also makes the same business operation usable from different entry points.

Imagine a function for changing an order's shipping address. A person may use an admin screen, a developer may use a command-line tool, and AI may use a connected tool. If each entry point sits on top of the same API, the changeable fields and validation rules can be managed in one place instead of being rebuilt for every interface.

This is where MCP, the Model Context Protocol, often enters the discussion. MCP provides a shared way to expose information and tools to AI. Its tool specification includes use cases such as API calls, database queries, and computation.

Adopting MCP does not automatically create the business operations you need. Not every MCP tool must be backed by an API. Still, when existing business functions are already organized as APIs, it becomes much easier to expose them through MCP as well.

Even if the connection method or AI tool changes, the work itself remains: retrieve an order, check inventory, apply a change. Keeping those operations out of a single screen and available in a reusable form helps the next development effort too.

From writing replies to finishing work

Return to the product exchange example. Do we want AI to stop at saying, "Here is how to exchange the item"? Or do we want it to move the exchange process forward? The answer changes what we need to prepare.

First, the system needs to check the target order, purchased product, and shipping status. Then it checks exchange rules and inventory, decides what processing is required, waits for human approval if needed, applies the change, verifies the result, and leaves a record. Only then is the request meaningfully handled.

What matters here is not simply whether an API exists. The required operations must exist. If there is an API for reading orders but no way to register an exchange, that step remains with people. Even if customer-facing information can be retrieved, the operations needed by internal staff may not be available.

Function calling connects models to outside data and actions. A model requests a tool call, the application executes it, and the result is returned to the model. Directly operating a screen can also be an option, but for repeated work, APIs should usually be considered first because they make inputs, outputs, and executable boundaries explicit. They also make it easier to design human approval, stopping points, and audit logs.

A plausible answer and a completed system operation are different things. APIs are the connection point that lets AI turn a proposal into execution and then confirm the result.

Keep the day the tote bag handle changed

Once the route for operations exists, the next question is why AI would choose a given operation. Even if it can update an order, work cannot move forward if it does not know the exchange conditions or who handles exceptions. Alongside the "hands" provided by APIs, AI also needs a map for understanding the work.

That map includes polished manuals, but also small everyday changes. Imagine a company that sells several products online, such as tote bags and shoulder bags. One day, it changes the handle length of a standard tote bag from 12cm to 16cm.

Updating the product master tells us the current length. But it may not tell us which specification applied to older orders, when the change started, or why it happened. If a customer who bought the older version asks a question, answering only from the latest product data may create a mismatch.

Ideally, updates to product data are connected with the reason for the change, the effective date, and the approval record. Even before that system is complete, it is useful to record what changed, when, and how. If the person responsible and the source material are also recorded, later investigation becomes easier.

If product data and sales trends can be obtained through APIs, those records can be checked alongside the change history. If sales rose after the change, it may become a clue. But the interpretation changes if advertising, pricing, or other conditions changed around the same time. Timing alone does not prove that the longer handle caused the increase.

The important thing is not to lose the material AI will need later. Knowing the current correct value and keeping the events that led there serve different purposes.

Start with short records like Memos

These records do not need to become polished reports every time. Memos is a tool for accumulating short notes, logs, and ideas on a timeline. When something happens, write it down briefly. Those small records become clues for looking back on the flow of work later.

In the ecommerce example, a simple note could be enough to start:

September 1: Decided to change the handle length of standard tote bag A from 12cm to 16cm in response to feedback that it was hard to carry. Confirmed by the product planning owner. Planned for shipments from September 10. Specification document attached.

This is a fictional note, but the difference from simply writing "changed handle length" is visible. It identifies the product, the reason, the decision date, and the intended effective date. If the switch actually happened on September 10, that result can be added as another record.

The value of short notes is that they do not stop the work. Meeting decisions, customer feedback, and implemented changes can be recorded as they happen. If later searches can follow product names and dates back to related materials, the team relies less on one person's memory.

Of course, a note is not automatically final truth. Draft ideas, approved decisions, and actual changes should be distinguishable. AI also needs those clues to tell what was fact and what was only planned.

One practical start is to let AI trace natural-language notes, compare them with product data or sales trends obtained through APIs, and summarize what happened before and after a change. You do not need a perfect database from the beginning. Keep the original records, use them, and then improve how they connect to product information and search.

Try one job end to end first

Once APIs and business information both seem important, it is tempting to prepare everything before using AI. But if the use case is vague, it is hard to decide which operations should become APIs or which information should be connected.

Start with one job, such as product exchange. Retrieve information, prepare a response, pass through human approval, execute the operation, and leave a record. Test whether that limited flow can run end to end. If a necessary operation cannot be called, prepare the API. If an old specification cannot be identified, connect the change history. The place where the flow stops shows the next priority.

At the same time, measure whether the work was handled correctly, how much human work remained, and how much time and cost each case required. Early attempts may be expensive, but once value is confirmed, the team can see what should be preserved while improving the flow. If a faster search begins to miss necessary records, that improvement should be reconsidered.

Some decisions about data structure and search should be made after seeing the actual work. But the ability to call necessary operations from outside the screen, and the ability to trace the reasoning and result, are foundations no matter which AI is used.

When thinking about the next internal system, imagine not only the person sitting in front of the screen, but also the AI that may take over part of the work. Is there an API for the operation you want to delegate? Is the information needed to choose that operation preserved?

We have built internal systems around human screen operation. Now we need to change them so work can also be handed to AI. That is why internal system APIs matter.

This article was reconstructed from a conversation between @theaktky and Kijitra's Ikeda.