At the recent AquaSur 2026 conference, our CTO, Abdías Ponce, shared a key insight regarding the use of artificial intelligence: the performance of these systems does not depend solely on the model, but on the context in which they are used. A model may have high technical capabilities, but without sufficient information about the process, constraints, and objective, its response will be incomplete. The difference lies not in having access to AI, but in how it is integrated into operations.
Prompting: the model responds based on the context it receives
Language models do not understand production processes or business criteria. They generate responses based on the context provided. Therefore, for the same task, the result can vary significantly depending on how the request is phrased.
A practical way to reduce this variability is to structure the prompt around five dimensions:
role + context + task + format + constraints
A specific example in a processing plant: when the goal is to analyze a production report to assess efficiency and identify bottlenecks, a typical prompt might be"Summarize this document." The result will be descriptive, but not necessarily useful for decision-making.
If, on the other hand, it is structured as follows:"Act as a process engineer with 20 years of experience in salmon farming. Analyze this document summarizing the efficiency of a processing plant and, based on this analysis, identify the three main bottlenecks. Present them in a table that includes the problem, impact, and suggested solution, considering only solutions that can be implemented quickly and do not require an investment exceeding $50,000 USD," the model is given a specific technical role, a clear production context, a concrete task, a defined output format, and real operational constraints. The result ceases to be a summary and becomes a direct input for the operation.
Chain of Thought: Structuring Reasoning Step by Step
The "chain of thought" is a technique that involves explicitly asking the model to break down a problem into steps before providing a conclusion. The goal is not to obtain a longer answer, but rather a structured one. In fields such as salmon farming, where decisions depend on multiple variables, this helps avoid incorrect oversimplifications.
For example, when evaluating a feeding strategy at a fish farm, a direct prompt such as"What is the best feeding strategy for this farm?"tends to generate generic responses. In contrast, structuring the analysis into five steps—evaluating biological variables, analyzing environmental variables, identifying operational constraints, comparing strategy alternatives, and concluding with a justified recommendation—guides the model through an analytical process. This allows us to understand how it arrives at the recommendation and assess whether it is consistent with operational reality.
Few-shot learning: transferring operational criteria through examples
Few-shot learning involves providing examples within the prompt so that the model understands how to respond. The model is not trained, but its behavior is adjusted based on patterns. This is useful when the problem is not a lack of information, but a lack of consistency in the criteria.
A typical scenario in a processing plant: the goal is to classify production events based on their criticality. A basic prompt such as"Classify these events based on their criticality"may vary depending on how the model interprets each case. If, on the other hand, examples are incorporated—such as a complete line shutdown due to a power failure as critical, a color deviation outside the range in 5% of the batch as medium, and a slight increase in defects with no impact on the final classification as minor—the model not only responds but also replicates the provided standard, enabling greater consistency across teams and decisions.
RAG: Respond using information specific to the operation
The RAG (Retrieval-Augmented Generation) approach allows a language model to rely not only on general knowledge but also to incorporate company-specific information before generating a response. Simply put, RAG retrieves information from various sources, converts it into a common format, and makes it available to the model as context.
A specific case: understanding the factors that led to a decline in quality over the course of a week at a salmon processing plant. The challenge lies not in the question itself, but in locating the relevant information. In a processing plant, relevant data is spread across multiple areas: quality (defect reports, color, final quality), production (line speed, yield, fillet count), sales and HR (shifts, staffing, urgent orders), and infrastructure (network configurations, systems, support).
Each of these sources uses different structures and serves different purposes. Without a mechanism to integrate them, analysis relies on manually cross-referencing information. What RAG does is act as an intermediary in that process: it takes these heterogeneous sources, transforms them into a common language, and, when a query is made, retrieves the relevant information from each area as a unified context. The prerequisite for this to work remains the same: the data must exist, be accessible, and be traceable.
Agents and multi-agent systems: from analysis to implementation
An agent is a system that interprets information, makes decisions, and performs actions on other systems. This is possible because the model connects to external tools (ERP systems, production systems, internal software) and acts directly on them.
Here is a specific example from a salmon processing plant: the plant is operating at full capacity, and in real time, a decline in quality begins to be detected in a batch—for example, an increase in melanosis. In a traditional workflow, this involves identifying the problem, manual validation, coordination between quality control, production, and sales, adjustments to the systems, and, finally, determining the product’s destination.
In a multi-agent approach, this same scenario is resolved as an integrated workflow: a first agent analyzes real-time quality data and detects the deviation; a second agent executes the operational decision, halting the original assignment and automatically redirecting the batch to another production destination; in parallel, a third agent assesses the business impact and identifies available alternatives.
The difference lies not in the analysis, but in the fact that the decision is executed directly on the transaction. This reduces response times, eliminates intermediate steps, and standardizes responses to recurring events.
Abdías Ponce — CTO, Lythium
The change isn't technological; it's operational
The tools for working with AI are already available. Prompting, chain of thought, few-shot learning, RAG, and agents are not new technologies, but rather ways to structure the use of models within real-world processes.
The difference between those who are capturing value and those who aren't lies not in access to technology, but in how they define their problems and how they integrate AI into their operations. And those remain human capabilities.
The focus, then, is on how AI is integrated into daily work: what context is provided to it, how requests are structured, and what information it has access to. The key shift is to stop using AI as a transactional tool and start working with it as a colleague. Not as a replacement, but as another component within the operation.