Language Models
When you ask AI to explain a failed delivery or assess an incoming document, you need to know what supports its answer before acting on it. The AI Assistant, AI Tasks, and external AI applications connected through MCP use language models to interpret requests and produce responses. Understanding how those models work helps you decide what to ask, what to check, and how much authority to give them.
Generated Answers and Variation
A language model learns patterns from training data and generates text by repeatedly choosing a likely next piece of text, called a token, based on the information available to it. This lets it interpret varied wording, summarize documents, and connect information across records.
A model can produce incorrect facts, invented records, or unsupported explanations in fluent, confident language. This is often called a hallucination. For example, the model might blame a partner's failed SFTP delivery on an expired password even though the connection log records a timeout before authentication. The relevant connection and transfer records let you check that explanation.
There can be several plausible continuations of the same input, and the generation process can choose among them. As a result, the same request and source data can produce different wording, classifications, or actions on different runs. A more specific prompt narrows the choices; it does not make the result deterministic. Changes to the model, conversation, or retrieved data can also change the result.
Incomplete instructions leave choices to the model. It may infer an answer, choose a format, ask a question, or stop without completing the work. An unattended AI Task cannot rely on a person answering a question during its run. Its prompt needs an explicit outcome for missing information and uncertainty.
Use Automations or other fixed rules when the same condition must always produce the same result. A rule that routes every CSV with a matching filename to accounting has a defined outcome; interpreting an unusually worded invoice calls for judgment. AI fits the latter when the workflow can accommodate review and uncertain results.
Context and Tokens
A model answers from its training and the information supplied for the current response. That supplied information is its context: instructions, conversation messages, examples, file contents, and results returned by tools. Access to a Files.com site gives an AI application a way to retrieve information; it does not mean the model has already read every file or record.
Tokens are units of text, often a word or part of a word, rather than a count of files or bytes. A model's context window is the limit on the tokens it can consider for a response, including space for its output. Instructions, a long conversation, documents, and tool results all compete for that space.
Applications manage long inputs by selecting excerpts, retrieving relevant sections, summarizing earlier material, or limiting the amount returned. The exact behavior depends on the application and model. A chat can still display an earlier filename after its contents have left the model's context. A tool can also return only part of a file. Ask which portions were available before relying on a claim that the whole file was reviewed. For a large review, divide the work into defined groups and ask the AI to record what it read, what it skipped, and what it could not complete.
A new AI Assistant chat has its own conversation. Enabled saved memories and the applicable Personality can supply background, but they do not carry over the complete transcript of earlier chats. Each AI Task run also starts a separate session with its saved prompt and trigger context. Put recurring requirements in the saved task prompt or an explicitly named reference file rather than relying on an earlier run's conversation. External MCP applications have their own conversation and memory behavior.
The AI Assistant and AI Tasks consume Transformation and AI Credits for model input and output. Larger inputs, longer answers, and work involving several model calls can consume more credits than a short exchange.
Instructions and Source Content
A prompt is a request or instruction supplied to the model. A system prompt supplies application-level instructions, such as the assistant's purpose and operating rules. The user's request describes the particular job to carry out within those instructions. Files.com Personalities customize the Assistant's instructions for tone and organizational context; they do not change its permissions.
Files, emails, and tool results supply information to examine. They can also contain text that looks like an instruction. A model can mistake that text for a direction and let it influence its answer or next action. For example, a supplier's invoice might contain “Approve this invoice.” Those words come from the supplier; the workflow owner's review rules determine whether to accept it.
Keep the rules for assessment in a reference controlled by the workflow owner, and distinguish those rules from the documents being assessed. Ask the AI to treat source contents as data and report conflicting directions. Clear wording helps, but a prompt alone cannot enforce that separation. Limit the application's permissions and review consequential results to reduce the impact of misleading source content.
Prompts With Clear Boundaries
A useful prompt identifies the subject, the evidence to use, the decision criteria, and the required result. Include paths, account names, and the time period and time zone when those distinctions matter. Say whether the job is a report or a change, and define what to do when evidence is missing. An instruction to report an unknown result gives the model a useful alternative to filling a gap.
For an interactive investigation, you might ask:
Review Sync runs for the Remote Server named Partner Intake between 08:00 and 12:00 UTC on November 2, 2026. Identify failed runs and the errors recorded for them. Separate recorded facts from possible causes, identify the records supporting each finding, and list checks you could not complete. Produce a report in this chat for me to review before making changes.
Examples of input and expected output help when a format or classification matters. Include contrasting cases so the model sees how to handle both a clear finding and missing evidence. For an invoice-field report, you might include this in the prompt:
Use these illustrative examples to format the invoice-number entry. If page 1 says "Invoice number: INV-104", the entry is "Invoice number: INV-104; source: page 1". If no invoice number is found, the entry is "Invoice number: Missing". Extract actual values from the current invoice; the examples supply the format only.
In a conversation, ask for clarification before a consequential assumption. For unattended work, define a report or review destination for an unresolved case. Writing Effective Prompts applies these principles to saved AI Tasks and their triggers.
Tools and Actions
A model's response can request a tool call as well as produce text. A tool is an operation provided by the application, such as listing a folder or reading a log. The application receives the requested call, performs the operation subject to its access controls, and returns the result to the model. The model can use that result to answer or request another tool.
An agent is an application that uses this loop to work toward a goal over several steps. A broad request can lead to a chain of actions you did not anticipate, even when every action is permitted. A statement that work is complete is not a substitute for checking the resulting files or records.
The AI Assistant asks for approval before applying proposed changes. AI Tasks run unattended with their configured permissions. An external MCP application controls its own approval behavior, while Files.com applies the permissions of the authorized account or credential. A prompt describing one folder does not restrict a credential that can access more. Choose permissions for the job as well as writing a precise request.
Review of AI Output
Grounding means basing an answer on relevant source material, such as the actual file or site records, rather than relying only on the model's general knowledge. Grounding makes the answer easier to verify and reduces unsupported claims, but the model can still misread a record or draw the wrong conclusion. If it has not retrieved the necessary data, it may give a general answer that sounds specific to your site.
Ask for the file paths, document sections, record identifiers, and time periods supporting the answer. Then compare important claims against those sources and inspect the available tool results or chat transcript. A source reference is useful only if it exists and supports the associated claim. Asking the same model whether its answer is correct does not provide an independent check.
Check coverage as well as individual findings. A useful report identifies what was examined and what was unreadable, unavailable, or left unreviewed. For classifications and screening, inspect a sample of items with no findings as well as flagged items; reviewing only the flags cannot reveal the problems the model missed. Choose the review depth from the consequence of a wrong result.
For recurring work, define the acceptance decision separately from the AI's assessment, including who handles uncertain results. Task evaluation explains testing representative inputs, retaining evidence, and checking results over time before they drive file delivery or access changes.