Imagine two people trying to reach the same destination. One has an old car with a paper map; the other, a modern vehicle with integrated systems, real-time navigation, route optimization and intelligent assistance. Both are still driving, and both remain responsible for their decisions. But one of them will move faster, react quicker, process more information and reach the destination far more efficiently. That, in essence, is what Artificial Intelligence represents today. As Sam Altman, OpenAI’s CEO, has put it: “AI will not replace humans, but humans using AI will replace those who don’t.”
But the great car only improves your travel experience; it does not turn you into a good driver. To really take advantage of AI, the Anthropic AI Fluency Course defines four steps that matter. The first is delegation: you must know where you want to go and understand what AI can do well. The second is description: you must be able to transmit that intention to the AI, giving it the role to play, the context it should use and the rules it must follow. If you cannot configure the car’s system and type the destination into the GPS, the supercar will not help you. Once you start driving, you need discernment: the AI will suggest possibilities, and you remain responsible for checking that the route it picked is actually the right one for you. How many times has the GPS chosen a fast route full of tolls, or one that simply does not feel safe? With AI, it is the same. The last step is diligence: never sign your name on something you cannot explain. You can delegate a task, but never the understanding behind it. In our analogy, you can switch on the autopilot, but you should not trust it so completely that you would no longer know how to take back the wheel when something goes wrong.
In short, the four Ds form a chain. Delegation is about knowing where AI helps and where it does not. Description is about giving it the role, the context and the rules it needs to do the job. These two come before the model is used. The other two come after: discernment is checking that the route the AI chose is the right one — that the approach makes sense and the output is actually useful and correct — and diligence is the awareness that, however good the assistant, the signature on the final answer is yours. Throughout this article, as we walk through the ways AI now connects to the PSR models, these four steps are worth keeping in mind: they are what separates using AI well from merely using it.
AI’s traditional use
The first step away from the paper map was the rise of the LLMs. The earliest way of using them was the simplest one: write a message (a prompt), send it to the model and read the answer that comes back. How does this actually work? LLMs (Large Language Models) are trained on enormous text datasets. The words are first tokenized, i.e., broken into small pieces and converted into numerical IDs the model can process. From that training, the model learns the probability that a given word or phrase should follow another in a given context and uses those probabilities to generate new content on demand. That is what we call generative AI. It produces emails, summaries, code snippets, and drafts of reports. The result is genuinely useful, but it does have limits.
A generic LLM is constrained by the dataset it was trained on, and retraining a model is expensive enough that it cannot be done in real time. The consequence is a lack of context. If you ask the AI about something specific to PSR that was not part of its training, it does not admit it; it guesses, and what is worse, it does so with complete confidence. Ask it, for instance, “what is a renewable station in SDDP?” and the model will answer using public information about the physical concept of renewable plants, something like: “A Renewable Station is a power generation facility that produces electricity from naturally replenished energy sources such as solar, wind, hydro, or biomass.” This is what we call hallucination.
Grounded intelligence: an assistant that knows PSR
To close that lack of context, the LLM must somehow access PSR’s own knowledge. Since fully retraining the model with PSR documentation would be expensive, imagine instead that we can plug a pen-drive into the LLM at the moment it needs to be answered. The technique that does precisely that is Retrieval-Augmented Generation (RAG). It works in four small steps. First, the PSR documentation (manuals, methodology notes, examples) is split into smaller pieces called chunks, tokenized and embedded into a vector index, so that it speaks the same numeric language the LLM uses to generate text (0). When a user asks a question (1), the question itself is also vectorized, and a similarity search using cosine distance returns the passages whose meaning is closest to it. Those passages are injected into the prompt as context, so the LLM receives both the user’s question and the documentation it needs to answer it correctly — exactly the description step we talked about in the opening paragraph (2). The LLM then composes a grounded answer from that evidence, not from its general training (3).
The PSR Assistant uses exactly this technique to let users ask specific questions about PSR. It does not only answer the question; it also returns the link to the relevant page in the PSR Knowledge Hub , so the user can double-check the information. Beyond avoiding hallucinations, the real gain is time: instead of searching across hundreds of pages, the user gets a direct, sourced answer. The Assistant has two siblings built on the same pattern, but grounded on the source code of PSR libraries— one for PSR Factory , our Python automation API, and one for PSRIO, our BI tool. For users who are not yet fluent in those libraries, they short-cut the blank-page problem: ask for a typical script and get a working starting point you can adapt.
Figure 1 — RAG anchors the LLM on PSR’s own documentation, replacing hallucinated definitions with grounded, sourced answers.
Agentic AI: from answers to actions
But what if AI could go beyond generating content and start executing tasks? Imagine that the manual work an analyst performs every day — discovering the input data of a model, editing that data, running cases on-premises or on the cloud, visualizing the results — could be turned into automated tasks triggered by a single request in natural language. This is the third step in the journey: from generative AI to agentic AI, a system designed to execute complex workflows by combining autonomous planning, long-term memory and the ability to interact with external applications. But if the LLM still has limited data, how can it possibly know about our data?
Modern AI platforms — OpenAI’s, Anthropic’s and others — now support customized branches that give the model access to external applications. The model then behaves as an orchestrator: it uses those branches, together with its own LLM, to execute tasks for the user. To execute a task automatically, the model needs access to a customized code function that it can call, and that can in turn reach external data sources. The standard way to make this connection is the Model Context Protocol (MCP), an open protocol that lets any LLM interact with external systems through a consistent interface. An MCP server publishes a catalogue of tools — typed functions, each with a clear description — that the model can browse and invoke. The PSR Agent is our MCP server. It exposes functions that, through the PSR Factory Python API, talk to PSR models databases. Orchestration usually begins with an internal plan of what should be done; the model then compares this plan against the descriptions in the tool catalogue, by similarity, and selects the tool that best matches the task at hand.
For the AI to perform all of that well, it needs a good description of how these tools works and which workflow should be used to each task. But it would be tedious to write those instructions from scratch every time. The natural solution is to package them once and reuse them. This is the idea behind Skills: bundles of instructions, examples and helper scripts that the agent loads on demand when it recognizes a familiar task type. Where MCP gives the AI access, Skills give it expertise — the right order in which to call the tools, the common pitfalls to avoid, the PSR house style for reporting results. A typical workflow is illustrated below; at the end of it, the LLM is used once more, this time to write up the result or to report a success or failure message.
Figure 2 — The PSR Agent: an AI model uses its LLM to discover and load Skills for domain expertise, accesses PSR tools through MCP, and reads from and writes to the SDDP database via PSR Factory.
The toolbox PSR built into the Agent is shaped around the parts of the day that take the longest. Tracking down an object, navigating its relationships or filtering elements by condition becomes a single question, rather than a sequence of tabs and clicks through the interface. Repetitive bulk operations — updating capacities, scaling time series, creating new objects — can be executed automatically in a safe-copy mode that preserves the original case. Simulations in SDDP, OptGen and NCP can be launched directly from the conversation, with the Agent monitoring execution status and extracting structured summaries of errors, warnings and convergence information from the run logs. Scenario comparisons, revenue calculations and result analyses can also be performed through the conversation; a single instruction is enough to package the outputs and notify the team.
In summary, the current set of tools was designed to reduce the repetitive operational work traditionally performed through the graphical interface. The project is intended to evolve incrementally: as new recurring workflows and user needs are identified, additional capabilities will be incorporated into the Agent over time.
In practice, a single prompt such as “update Plant X’s installed capacity to 1,350 MW, run SDDP for the 2026 horizon, and email the results to the operations team” already maps to a workflow that previously required several manual steps across different interfaces. The user still reviews the proposed actions and validates the final answer, but the operational friction drops sharply.
The next step: a reasoning layer
Grounding the LLM in PSR knowledge and connecting it to PSR tools covers the “information” and “execution” parts of the problem. The third piece, still in development, is the analysis layer: an agent that does not only answer questions or run operational tasks on request, but interprets simulation results, forms hypotheses about what is driving them, and pulls the data needed to test those hypotheses.
The prototype, currently under development, is structured as a multi-agent pipeline. An orchestrator dispatches the user request to specialized sub-agents — one for problem classification, one for cause hypothesis, one for data discovery — each with its own narrow set of tools. The orchestrator then combines their outputs into a single synthesized answer, with traceable evidence the analyst can audit step by step.
Figure 3 — Reasoning agent under development: specialized sub-agents classify the problem, generate hypotheses and discover data, then return a synthesized, evidence-backed analytical answer.
Taken together, RAG, agentic AI and the reasoning layer trace a clear path for AI inside PSR: from explaining the models, to operating them, to reasoning over their results. The goal is not to replace the analyst, but to take the routine work off the analyst’s plate, so that the time saved goes to what really needs human judgement.
