The implementation layer answers two questions: what capabilities a task is done with, and how the process can be seen and checked. Capabilities fall into two kinds. General capabilities, such as understanding, planning, retrieval, running programs, scheduled execution and notification, decide whether a task can be done at all. Finance-specific capabilities, such as market and fundamental data, portfolio calculations, suitability checks, trading interfaces and checks on whether investment statements are compliant, decide whether it is done right. How capabilities are organized depends on the task. Tasks whose path is uncertain and depends on personal circumstances are assembled on the spot by the agent; tasks whose path is fixed, which serve many people and require consistent quality, use fixed workflows. A lasting relationship cannot live only in a series of conversations. The mandate, the portfolio and the record of performance must be stored as long-lived objects, with a point-in-time record of what was known at the time. The user must be able to see at a glance what is under way and what is waiting for them, and must be able to replay every past decision.
Completing a financial task takes two kinds of capability. General capabilities decide whether the task can be done: understanding what the principal asks for, breaking it into steps, retrieving material, running programs for calculation, running on schedule, sending notifications, and asking for instructions and waiting for confirmation. Finance-specific capabilities decide whether it is done right: accurate, time-stamped market and fundamental data; calculation of portfolio return, risk and attribution; suitability and constraint checks; trading interfaces and execution rules; and checks on whether investment statements are compliant. Without general capabilities the task cannot be completed. Without finance-specific capabilities the task is completed, but the result may be wrong.
Perrow (1967) distinguished tasks in organizations along two dimensions: how many exceptions arise, and whether a ready method of analysis exists when one does. Tasks with few exceptions and clear methods suit standardized procedures; tasks with many exceptions and unclear methods require judgment on the spot. The same holds for how an agent's capabilities are organized. Researching a company or answering a personal question has a path that cannot be fixed in advance; it suits an agent that calls capabilities as needed and assembles them on the spot. A daily market summary, a maturity reminder or a periodic portfolio check-up has a fixed path, serves many people and requires consistent quality; it suits a fixed workflow that has been evaluated. The two can connect: while assembling on the spot, the agent can call a published fixed workflow as one of its capabilities.
On-the-spot assembly or a fixed workflow
The horizontal axis is how fixed the task's path is; the vertical axis is how many people the same task serves, and how often. Tap a task to see which way of organizing suits it.
Tap a task.
A conversation is temporary. When it ends, the agreements, judgments and to-do items made in it are scattered through the chat history. A continuing delegation needs objects that persist: the mandate, the portfolio, the assets being watched, research notes, pending items and the record of performance. The agent reads these objects each time it starts work and updates them when it finishes; the user can view and edit them directly, without searching through past conversations. Objects let the relationship span conversations and devices, and they keep the agreements and records intact after the agent or model is replaced.
Financial data are revised. Company earnings are restated, macroeconomic data are corrected, and index constituents change. Croushore and Stark (2001) built a real-time data set for macroeconomic research precisely because judging past decisions with revised data leads to wrong conclusions. An agent's records should likewise be kept point in time: when a decision was made, which moment's data it used, and which version of the mandate and of the model. In a review, the decision made at the time is judged with the data available at the time, not condemned or excused with information that only became known later.
Norman (1988) called the difficulty users have in judging what state a system is in the "gulf of evaluation". If users cannot see what the system has done, how far it has got and whether it needs them, they can only guess or ask again and again. For a continuing agent, three things matter most and must be visible at a glance: which tasks are under way and when each will next run; which items are waiting for the user's confirmation, and by what deadline; and which checks were recently blocked, and why. If this information is scattered through the chat history, the user has to search for it item by item.
If a decision records all its inputs, the clauses it relied on, the version of the model used and the result of execution, it can be replayed: run again with the same inputs to check whether it reaches the same conclusion. Peng (2011), discussing reproducibility in computational science, pointed out that results can be checked by others only when the data and code are made available. Replay has two uses. When a dispute arises, it reconstructs how the decision was made at the time. Before a model version is changed, it tests on past inputs which decisions the new version would make differently, so that users can be told of the change in advance.
Choose a replay.
Build general and finance-specific capabilities separately; choose on-the-spot assembly or a fixed workflow according to the task; store the relationship as objects with point-in-time records; make progress and pending requests visible at a glance; and allow every decision to be replayed.
Data, calculation, constraint checks, trading interfaces and compliance checks decide whether the result is right, and need evaluating on their own.
Tasks with fixed paths that serve many people become evaluated fixed workflows that the agent can call.
Keep every piece of data and every decision point in time, and review with what was known at the time.
Keep inputs, clauses and model versions; replay to test before changing versions, and tell the user of differences.