From how AI works to Hermes: how a probability machine that guesses the next word comes to work like a team
August 28, 2026 | SKYWARE ACADEMY
On August 28, 2026, we held an in-house AI lecture. So that planning and operations staff could join developers, we organized it in four stages: starting from how an LLM produces an answer, then how to call it through an API, how to put it to work effectively, and finally ‘Hermes’, a multi-agent setup in which several agents split up roles. Here is a condensed version of the 23-page lecture deck.
01. How AI works · Choosing the next word by probability
An LLM reads the entire input and repeatedly assigns a probability to each candidate for the next word, then picks one. After “The weather today is,” candidates might come up as “nice” at 41%, “cloudy” at 33% and “how?” at 26%. Once one is chosen, the model recalculates from the beginning with that word included. The key point is that the probabilities are readjusted as the context grows longer.
Read the full inputList next-word candidatesReadjust probabilities based on contextPick one wordRepeat from the start
- temperature · top-kKeep only the top k candidates (top-k) and control randomness with a value from 0 to 1 (temperature). Lower values give consistently similar answers; higher values give more varied but less stable answers.
- How models are trainedMask the next token in a sentence that contains the correct answer, have the model predict the probabilities, then adjust the parameters to reduce the error against the correct answer. A model is the result of repeating these four steps countless times.
- How to improve answer qualityUse a model with more parameters (7B → 70B), or have it generate internal reasoning tokens before the final answer (reasoning). The trade-off is that time and cost go up as well.
- LimitationsBecause it operates on probability without a verification mechanism, hallucinations occur. The amount of context it can handle at once (the context window) is also limited, and computation rises sharply as the context grows.
02. Using the LLM API · One JSON request
An API call ultimately comes down to a single JSON request. Parameters specify which model to call, how to pass along the conversation so far, how much randomness and length to allow in the answer, and what structure the answer should take. We grouped the eight parameters covered in the lecture by purpose.
Key request parameters
| Category | Parameters | What they do |
|---|---|---|
| What · with which conversation | model · messages | The name of the model to call, and the conversation built up from alternating user and assistant turns |
| How freely | temperature · top_p · top_k | Randomness in candidate selection, limiting candidates by cumulative probability, limiting the number of top candidates |
| How deep and how long | reasoning_effort · max_output_tokens | Level of internal reasoning (low · medium · high) and the cap on output tokens |
| In what shape | response_format · json_schema | Force the answer into a defined JSON structure so programs can read it directly |
There were two practical takeaways. Since tokens equal cost, don’t keep passing an ever-growing conversation in messages. And when integrating with a system, lock down the response structure with json_schema to eliminate parsing errors.
03. Putting LLMs to work · Have it ask questions back, and steer the flow with commands
- Reverse questioning“Ask me the essential questions you need in order to do X.” Instead of getting an answer right away, have the model first ask about missing conditions. This works best when requirements are vague.
- / commandsSet the final goal with /goal, draw up and review a plan in advance with /plan, then execute. Separating goal → plan → execution reduces the chance of going off track midway.
- From prompt engineering to loop engineeringRather than one good prompt, running a loop of Goal → Act → Observe → Adjust produces more stable results.
- Harness engineeringBuild a framework that controls the AI with clear guidelines and rules. It means deciding in advance what it can and cannot do and in what order it should check things.
04. Hermes · From a single agent to a team with divided roles
The lecture closed by comparing a structure in which one agent does everything with a structure in which a coordinator (orchestrator) reads the request and hands the work out to specialized roles. In the lecture, the latter was called Hermes.
Single Agent vs Hermes
| Category | Single Agent | Hermes |
|---|---|---|
| Role structure | One agent does everything | Coordinator and specialized roles are separated |
| routing | Chooses only the next action | Chooses the roles and order that fit the request |
| Execution | Mostly sequential within one session | Parallel and sequential across independent sessions |
| Review | Self-review | Reviewed by an independent reviewer |
The Hermes structure: three roles under the orchestrator
- 1ResearcherGathers sources and facts. Brings evidence instead of guesses
- 2ImplementerWrites the code and tests. The one who actually does the hands-on work
- 3ReviewerFinds defects and risks. An independent review, separate from whoever built it
Role separation+Parallel sessions+Independent review=A clear jump in quality
There were five advantages: higher quality, an independent reviewer, automatic session management, self-learning and parallel work. There was one drawback: token usage goes up. The conclusion was to use it for work important enough to justify the cost. (Reference: Anthropic, How we built our multi-agent research system, 2025)
This lecture was the first session in SKYWARE’s effort to move internal AI use from the “trying it out” stage to the “building it into how we work” stage. The next session will cover a case where we applied a harness to a real project.