--- title: "Data and context for AI agents | Atiende" description: "Customers, documents, requests and tasks form a system of relationships. Atiende: AI agents with human oversight, designed around your operation." url: https://useatiende.ai/en/producto/datos-contexto lang: en alternates: es: https://useatiende.ai/es/producto/datos-contexto en: https://useatiende.ai/en/producto/datos-contexto updated: 2026-10-06 --- # Information connected to what it means for your business. Customers, documents, requests and tasks form a system of relationships. We design that structure so every answer and action relies on the right entity, its state and its permissions. ## Define business objects A customer can have multiple branches, bookings or files; a document can belong to a request and a particular version. Modeling those relationships allows precise information use. The aim is not to replace company vocabulary but to make it explicit so people, interfaces and automation refer to the same object. ## Identity and source of truth Similar names are not sufficient identifiers. The design agrees how records relate across systems and which source governs each attribute. When discrepancies arise, the difference is retained and reviewed. This prevents copied data or an old conversation from silently replacing the official record. ## Permitted context for each user Information retrieval depends on role, organization and query purpose. Permissions apply before an answer is built, not after sources have been mixed. The design also defines which data a task requires and which should remain outside summaries and operational history. ## Time, versions and changes A policy may have changed and a booking may have been canceled since the last message. Context includes when data was queried and whether it needs refreshing before action. Versions, states and provenance help reconstruct why an answer was reasonable using the information available at that time. ## How data context is evaluated in a pilot The test is whether the system identifies the right entity given imperfect inputs: a name spelled differently, a customer with several branches or a document with two versions. Pairs of near-identical cases are built to see whether they get mixed up. Then each answer is checked to confirm it cites the source, the query date and the permission that allowed it. The outcome is compared with what an experienced person would conclude from reviewing the same records. - Correct resolution of similar entities without confusing them. - Discrepancies between systems detected and sent for review. - Rejection of queries that would cross data from another customer or department. - Refreshing data when the information queried may already have changed. ## What to prepare beforehand Context work depends on agreements that are not technical. You have to decide which identifier is the official one for each type of object, who fixes a duplicate record and which system prevails when two values disagree. It helps to gather a sample of real records with their flaws, because data quality sets the ceiling on what any agent can do. Data that is too sensitive to appear in summaries is also listed. - Catalog of business objects and their official identifiers. - An owner for the quality of each main source. - A sample of duplicate, incomplete or contradictory records. - Classification of sensitive data and retention rules. ## Limits and human oversight Organizing context does not make the underlying data correct. If a source is out of date, the system can only flag it, not fix it on its own. Record merges, ownership changes and corrections that alter history require human review, because an error here spreads to everything that depends on the data. Permissions and retention are reviewed periodically. - Duplicate merging only with approval from a responsible person. - A record of which source backed each important answer. - Permission review when roles or structure change. ## Questions for your team before you start They tend to reveal whether the main obstacle is technical or one of data ownership. - How do we know today that two records are the same person or account? - Who has the final say on each key piece of data? - Which information sits in emails or loose files? - Which data cannot leave its system under any circumstances? - How old can a piece of data be before it becomes risky? ## How it works 1. Identify business entities, relationships and terms. 2. Assign sources of truth and identification rules. 3. Apply permissions, freshness and provenance to each query. 4. Review discrepancies and refresh context before acting. ## Frequently asked questions ### Is this an ontology? It is a way to describe which objects exist in a business and how they relate. The technical term is useful, but the practical work is to define customers, cases, documents, states and responsibilities clearly. ### Do we need to centralize all data? Not always. The architecture can query existing systems and retain references. The decision depends on latency, permissions, quality and operational requirements. ### What happens if two systems disagree? An authority per data item or a reconciliation process is defined. The workflow must not silently choose the most convenient answer when disagreement affects a decision. --- Book a demo: https://useatiende.ai/en/demo Contact: ventas@useatiende.ai · https://useatiende.ai/en/contacto Sitemap: https://useatiende.ai/sitemap.xml · llms.txt: https://useatiende.ai/llms.txt