Preparing an agent in Tigy: prompts, knowledge and context

Choose the right layer

Instructions say what the agent should do and how to converse. The knowledge base contains approved documents to consult. Context is the information available in the current conversation. Tools connect the agent to other systems to check or change information within configured functions and permissions.

Uploading a file is not enough

Upload the document in Knowledge base and wait for processing. Then select the source in the prompt agent and save. A workspace file must not be assumed available to every agent.

Test a question answered by the source and one outside it. Correct organization, content and selection before compensating for a missing source with more instructions. This procedure is not custom model training.

Corrections belong to the current conversation

Fictional example: the caller gives DEMO-17 and corrects it to DEMO-71 before lookup. The agent should confirm the corrected identifier and use it in the tool. The destination must still verify authorization.

Do not assume DEMO-71 is automatically available in the next call. For continuity, configure an authorized external-system lookup. Ask for and confirm missing information without embedding one customer's data in shared instructions.

Reviewable history is not automatic memory

Runs allow investigation of records when available. A transcript useful to the team does not establish that the agent retrieves it next time. Explicitly define how continuity is obtained and which fields it needs.

Avoid copying complete real conversations into broadly accessible documents. Prefer synthetic examples and rules without personal data when designing instructions. Review sources and permissions with their owners before making them available for service.

Improve through a hypothesis and verification

For an incorrect policy, investigate the source. For an outcome announced without a query, review instructions and the tool. For an old number used after correction, check recognition, confirmation and submitted parameters. Each issue needs a different correction.

Change one layer at a time and repeat the problematic request alongside a valid case. Record the version and observations before publishing. Conversations help select changes; they do not promise automatic permanent learning.

Is knowledge configuration the same as fine-tuning?

No. Fine-tuning changes model parameters through additional training. Document selection prepares retrieval sources; prompts define instructions; tools query or modify external systems. The setup documented here promises neither custom fine-tuning nor automatic learning from every call.

Choose changes by cause: incorrect policies need source review; missing confirmation rules need instructions; stale status needs current-system retrieval. Test the failed case and a valid case afterward. Reviewable history does not mean another conversation automatically receives those records.

Locate the problem before choosing an adjustment

When an agent gives a poor answer, it is tempting to add another prompt rule. That helps when the issue concerns conversation behavior, but it does not fix every kind of failure. A missing policy needs an approved source. An order without current state needs a system lookup. An empty variable needs an absence-handling rule. An improper action requires integration validation. Diagnosing the right layer prevents the prompt from becoming a collection of patches that never addresses the cause.

At a fictional store, the agent asks again for an order number the caller just supplied. The information exists in the conversation; the issue may involve instructions to use previously supplied facts or how the identifier is confirmed. In another call, it gives an old deadline because the knowledge base contains a previous policy. Adding “be accurate” does not replace updating that source. In a third, an API returns a request under review and the agent announces completion: state interpretation and permitted wording now need attention.

Describe the observed failure before writing the solution. Record what the caller requested, which evidence was available, what the agent did, and the expected outcome. This small diagnostic exercise separates defects that look similar. A response missing information may result from an unattached document, an unavailable lookup, or an out-of-scope question. Each requires a different correction.

In this context, “training” means configuring and testing the agent's instructions, sources, context, and tools. It does not mean every call automatically changes the model or teaches a permanent rule. Improvement depends on deliberate team changes and verification of their effects. That distinction supports a repeatable process with explicit decisions rather than an expectation of spontaneous learning. It also makes responsibility clear when the next review finds that an old issue has returned.

Write observable behavior instead of vague qualities

Qualities such as “polite,” “intelligent,” and “efficient” communicate intent, but do not explain how to handle a difficult situation. Replace some abstraction with observable behavior. Instead of only “be concise,” instruct the agent to ask one question at a time and avoid repeating confirmed information. Instead of “solve the issue,” define the available lookup, the state permitting an action, and the alternative when the tool does not respond.

Organize instructions around role, goal, conversation, tools, and boundaries. The goal should be narrow enough to verify in a call. “Help customers follow their orders” is easier to evaluate than “delight every customer in every situation.” The latter may coexist as tone guidance but cannot replace a service definition. Include short success and exception examples without turning the document into a rigid script that ignores the caller's replies.

For each new rule, ask which test will reveal compliance. “Use the identifier corrected by the caller” can be tested through a call where the person changes one digit. “Do not confirm an update without the tool result” can be tested with a failure or pending state. If compliance and noncompliance cannot be distinguished, the rule may be vague or combine too many behaviors. Divide it until evaluation is clear enough for different reviewers to reach similar conclusions.

Avoid repeating the same instruction in multiple places using different wording. Besides complicating maintenance, repetition can conflict with another exception. When a rule changes, there should be a recognizable place to edit it. Preserve guidance about boundaries and unavailable information while simplifying. A short prompt that omits failure handling may look elegant but leave the agent improvising precisely in the hardest cases. Clarity matters more than either maximizing or minimizing prompt length by itself.

Use sources and context for different needs

A knowledge base should answer questions about approved information appropriate for the agent's audience. Initial context can supply facts available before the conversation. Tools can query or change systems during service when configured to do so. These capabilities complement one another but are not automatic substitutes. Putting a list of orders in a shared document does not create a current, authorized individual lookup.

For a fictional appointment operation, documents may explain service duration and preparation. Initial context may identify the requested location. Availability needs a lookup in the booking system. If the caller changes locations during the call, the conversation should reflect that correction and the integration should query the correct place. An initial value should not be treated as immutable truth when someone corrects their own request.

Explicitly prepare behavior for missing values. If context contains no name, the agent can use a neutral greeting; it need not invent a name or interrupt service to obtain one unnecessarily. If a missing location changes the answer, a short question resolves the issue. Distinguishing optional information from essential conditions prevents empty fields from causing needless blocks. It also helps determine which missing values indicate a genuine integration defect.

For documents, verify completed processing, agent attachment, and relevant content. Test a direct question, one requiring another passage, and one not covered. For tools, test valid results, pending states, and errors. For context, test correct values, empty values, and caller corrections. These separate checks show where information comes from and how the agent should behave when something is unavailable. Only then assess the complete conversation, where the capabilities appear together and may interact differently. A successful component test is useful evidence, but it does not establish that the whole customer request will be handled correctly.

Create a review that can be repeated after every change

An improvement process starts with a reference version and a small collection of representative calls. Include common requests, caller corrections, silence, out-of-scope questions, and integration failures. Record each expected outcome. Without a reference, a new version may appear better because it was tested with easier questions or because the reviewer focused only on the recently corrected issue.

Change one principal cause at a time when practical. If you change tools, rewrite instructions, and replace documents simultaneously, explaining the changed result becomes difficult. Urgent corrections may require multiple changes, but record them and preserve previous scenarios. The aim is not bureaucracy; it is making a regression understandable and helping the team identify what to investigate first. A clear version record also prevents different reviewers from evaluating different configurations by accident.

Assess both the reply and the actual result. An agent may say “I could not submit this” even though the request exists in the system, or announce success when nothing was created. For changes, check the record with the responsible team. For lookups, compare the reply with the information received. For guidance, check whether the rule appears in the approved source.

After publishing a version, review a sample of service interactions to discover variations absent from the original collection. Turn recurring failures into permanent tests and assign an owner for correction. A useful improvement cycle makes clear what changed, why it changed, and which evidence supports the change. It also preserves boundaries: if a source remains missing or an operation remains unauthorized, the agent should explain the restriction. More configuration represents progress only when it makes service correct, useful, and verifiable for the people relying on it.