Use knowledge.
Connect work effectively.

For a business, an agent is first a possible division of work. A person describes a goal; the system selects next steps within a defined scope, uses tools and checks intermediate results. The difference from a single chat response is the workflow across several steps. How much discretion makes sense depends on the task. It must remain possible to stop a case, correct it or hand it to a person.

A useful starting point is a recurring process with varied inputs and a recognisable outcome. Service enquiries, for example, arrive with product names, photos, earlier messages and incomplete version details. Employees find data, compare documents and transfer the result into a ticketing system. An agent can bring that preparation together. The expected benefit is less switching between applications and a more complete working basis for a domain decision.

The assignment should be more precise than “automate service”. A clearer goal would be: establish the product version for authorised enquiries, collect approved documents, identify missing details and prepare an answer with supporting evidence. This makes scope and completion visible. Sending a message, committing to a price or granting technical approval are separate actions; they are not implicitly part of a research task.

Not every task needs this discretion. Where inputs and steps are unambiguous, a fixed workflow may be easier to operate. Where a person mainly needs better answers or wording, an assistant may be sufficient. Agentic behaviour becomes particularly interesting when the next useful step depends on an intermediate result. The process should drive the choice, rather than the name of the tool.

Selection benefits from a short look at the work itself: how many variations occur, which information is regularly missing, and how does an employee recognise a completed case? Tasks are especially interesting when preparation takes substantial attention but the result can be checked clearly. An agent does not automatically stabilise a process with unclear accountability or constantly changing rules. Sometimes the greater initial benefit comes from better data, a clearer interface or a reliable connection between two existing applications.

Our fictional example begins with a question: “Which adapter fits our M-20 module, and which documents do we need?” Product approval D-01 names A-4 for version 2. Document mapping D-02 points to connection diagram P-11. Another note mentions A-5 only as an unconfirmed possibility. The goal is an evidence-backed draft answer, not a new product approval.

First, the system assigns the enquiry to an authorised case. If the product version is missing, it establishes it from an allowed source or prepares a targeted question. It then retrieves suitable documents and compares their scope. The note about A-5 must not carry the same weight as an explicit approval. The draft therefore identifies A-4 for the documented version and points to P-11.

The agent can then transfer the details into a case draft: product, version, request, supporting documents and unresolved points. The responsible person receives something they can work with directly. They do not have to reconstruct completed steps from a long chat history. The value lies in connecting research with structured preparation.

An approval applies to this specific draft and the intended action. If the content subsequently changes, the process must recognise whether another review is needed. An unclear version ends the run with a question. An unavailable tool leaves the case open. Both can be correct outcomes; invented completeness would not be a success.

The difference becomes visible at the handoff. Previously, a specialist might receive a forwarded message and begin the search again. A prepared case brings together the enquiry, confirmed version, relevant approval and matching diagram. The specialist can focus on the remaining decision. If a question arises later, the basis of the answer is still visible. Whether this preparation actually saves work should be tested with the employees involved, across the complete case.

The workflow needs an understandable outcome record: which sources were used, which fields were prepared and which decision is still outstanding? This brief handoff makes the agent useful within a team. A detailed technical trace can separately support operations and troubleshooting without burdening domain users with every internal model step.

A knowledge base holds approved content. Retrieval finds relevant passages for a question. A knowledge graph describes explicit relationships, for example between a product, version, adapter and instruction. An agent uses these access routes to complete a task. The components serve different functions and should remain distinguishable even when they appear in the same interface.

In the service example, a graph can reveal the connection M-20 → version 2 → A-4 approval → P-11 connection diagram. A keyword search may find every document while leaving the connections to the employee. A maintained graph makes the domain relationships directly queryable. This produces a practical benefit: required documents can be supplied together, and conditions such as a product version are less easily overlooked.

Within its assignment, the agent decides whether it needs a product lookup, document retrieval or structured query. It can recognise a missing version as a blocker and prepare a question. The graph itself does not thereby create a case, and the language model gains no extra permission. An action only occurs through an authorised tool with clear inputs and a verifiable result.

Not every agent needs a knowledge graph. A tightly scoped search interface may be enough for a small, clearly organised document collection. A graph becomes interesting where multiple relationships are regularly part of the question. Maintaining those relationships is essential: outdated or incorrectly extracted connections can misdirect the workflow just as unreliable documents can.

The same knowledge foundation can support several workflows. A confirmed relationship between a product version and an instruction matters to service, sales and internal training. Three agents need not independently infer that connection from text. A shared, maintained knowledge interface can improve consistency. Approving a relationship does not make every use identical, however: a sales case may have different document permissions and output rules from internal technical research.

An agent consists of more than a model and a prompt. In the architecture described here, a runtime environment keeps the assignment, current processing state and permitted next steps together. It provides tools, enforces limits and records results. This control and execution layer is often called an agent harness. Its quality helps determine whether a model call becomes an operable business process.

A case state may contain the confirmed product version, sources already read, open questions and a pending approval. It is distinct from a longer-term knowledge base. A provisional assumption from one run should not automatically become permanent company knowledge. A summary of earlier work also needs a relationship to its source and validity.

In a hybrid setup, sources, retrieval and case state can stay in a controlled environment. A local or approved external model can be selected for an individual processing step. The choice is made before transmission and accounts for the actual context. A more capable model is not a reason to pass additional data without review. It must also be known whether a tool itself uses an external service.

Tools form the boundary to business systems. A narrowly defined document lookup or the creation of a particular draft is easier to control than general access to an entire application. Read and write functions receive separate permissions. The agent can propose a desired step; the execution layer checks whether that exact step with those data is allowed.

Tool contracts specify mandatory inputs and expected responses. A search result may need a document identifier and version; a write request may need an unambiguous target and approved content. Invalid or incomplete results enter a defined error state. An agent should not have to improvise from a generic error message whether a case has already been created. Well-designed interfaces reduce this ambiguity and make verification easier.

Dependable permission design follows the assignment. A research agent does not automatically need rights to send, modify or delete. Tool access should use the required identity and appropriate data scope. The executing service checks permission again, even when the model offers a convincing justification for a call. Wording in a prompt cannot replace this technical control.

Approvals must make clear what a person is deciding. “Continue?” is often too vague. A suitable view names the intended recipient or record, the change and its content. In our example, it would show the specific case draft. Approval to conduct research is not approval to send a message or change master data.

Documents and tool responses may contain misleading instructions. They are treated as working material and must not redefine the workflow rules. The system therefore limits accessible tools, data scopes and network destinations independently of the model. It also needs conditions under which the agent safely ends processing or hands the task to a person.

Privacy and confidentiality also apply to intermediate state: retrieved text, approval information, error logs and stored conversation summaries. Each requires a defined purpose, access policy and retention approach. For a cloud route, review must cover the entire transmitted request, including attachments, metadata and outputs of earlier tool calls.

Testing starts with a collection of realistic tasks. Alongside common cases, it includes incomplete details, conflicting documents, missing permissions and unavailable systems. Each case has an expected outcome: a correct draft, a question, a refusal or a handoff to the responsible team. This separates domain success from activity alone.

Evaluation considers several levels. Were the right sources found? Were conditions preserved in the answer? Were tools called with valid parameters? Is the final state in the business system correct? Fluent text can still name the wrong item or prepare an unauthorised change. These error types need different checks.

Retries must be designed. An interrupted database query may justify another read attempt. An uncertain response to a write operation first requires checking whether the change already happened. A unique case identifier and idempotent interfaces can help prevent a resumed run from creating the same request twice. The target system must actually support this behaviour, and it must be tested.

A saved intermediate state does not resolve every failure. A permission may have changed or a document may have become outdated before execution resumes. Recovery therefore needs to define which preconditions are checked again. Long-running processes also need clear handling of expired approvals, unanswered questions and ownership.

A useful test set records the domain boundary too. For an M-20 enquiry without a version, the expected outcome is a question. For adapter A-5, a confirmed compatibility claim is wrong even if the answer sounds friendly and complete. An unauthorised person must not receive an otherwise correct answer. Such cases reveal whether the process understood the task and stayed within its limits. The tests should be developed with the people who handle those situations today.

An economic assessment starts with the current process. How often does the task occur? How much active handling time does it take? Where do cases wait for other teams? What rework is involved? Handling time and elapsed time are different measures. An agent may shorten research while a necessary domain approval still depends on someone being available.

The relevant comparison covers the entire new workflow. Automated preparation is followed by human review, corrections, handoffs and sometimes a complete manual restart. Initially, only the difference from the previous active workload represents potential time relief. Whether that becomes lower cost, additional capacity or better availability depends on how the business can actually use the released time.

Costs include more than model calls: integration, operations, knowledge maintenance and domain support all matter. A large share of complex exceptions can change the economics. A pilot should therefore consider different task types separately. An attractive average can conceal that the most important or frequently escalated cases still require substantial manual attention.

The distribution is worth examining. Alongside average handling time, assess particularly long cases and the reasons for handoffs. The denominator must also be right: cost per started enquiry differs from cost per accepted completion. Excluding abandoned cases or those fully reworked by hand makes a pilot look better than everyday operation. The comparison should cover the same task population and quality requirements.

The interactive model illustrates scale. Its inputs are assumptions, not measured performance. An investment decision replaces them with pilot data and adds implementation costs, ongoing support, quality requirements and risk. A numerically positive result is not sufficient when minimum domain requirements are missed.

A functioning process has an accountable domain owner. That role decides which tasks are suitable, what counts as a correct result and when a person takes over. Technical ownership covers integration, access, operations and changes. Both perspectives must work together: a poorly defined domain assignment does not become better simply because the application is more stable.

For employees, the handoff matters. A clear case identifies the proposed next step, its basis and the outstanding points. Corrections should be possible where people already work. If employees must copy between another chat window and several business systems, some of the expected value can disappear.

Feedback needs a traceable route. A wrong adapter could result from outdated master data, an unclear source, retrieval failure or an unsuitable model step. A general thumbs-down button often does not provide enough information to improve the process. A few domain-specific error categories, linked to the relevant case without unnecessarily duplicating personal data, are more useful.

Agents also change responsibilities. Faster preparation can make approval the bottleneck. Automatically combined information still needs owners who maintain its quality. A pilot observes these effects and incorporates them into work organisation, training and service agreements. Introducing agents therefore also means designing processes.

The introduction should leave room to observe real work. Joint trials reveal which information users actually need and where they do not trust a draft. That can lead to different input fields, a more compact evidence view or a targeted question. Employee training should explain not just controls but also the permitted scope, limits of the knowledge foundation and the intended correction route. This creates clear collaboration rather than hidden extra checking work.

A pilot begins with a clear slice of work: one type of request, a defined user group and a few necessary systems. In the service example, initial scope could be limited to preparing enquiries for one product family. The team documents the existing workflow and agrees on quality criteria, processing limits and expected relief. This establishes a basis for comparison.

Knowledge access and tools are then tested independently of the agent. Are product identifiers and versions correct? Can sources be referenced unambiguously? Can drafts be created safely in the target system? Only once these foundations work should agent logic connect the steps. A pilot should reveal which problems lie in data or process design and which arise from model selection and orchestration.

Before operational release, the process undergoes a limited trial with domain users, error-case testing and agreement on a handover route. The team decides who responds to incidents, how changes are tested and how work continues without the agent. Success is a usable workflow under real conditions, not the most impressive demonstration.

Scalevity brings together process consulting, knowledge architecture and software development: selecting the use case, connecting data and business systems, designing the interface and moving the application into manageable operations. The work extends beyond the prompt. It includes the handoffs between people, knowledge and tools where business value is created.

An expansion decision needs criteria agreed in advance. These include usable outcomes, acceptable review effort, controlled error cases and accountable operations. If the criteria are not met, the next step may be a smaller task, a better knowledge base or a more fixed workflow. That is not a failed pilot. Its purpose is to find the appropriate scope before a larger part of the business depends on the solution.