Community

By following the individual learning paths, you can gain up-to-date, practically applicable knowledge that provides a real professional advantage in today's job market. At the end of each path, an exam and official certification are available, validating the knowledge and competencies you have acquired in a standardised way.Some of the full training materials are available exclusively to employees of companies with partner status. Drawing on our experience, however, we are also able to put together learning packages and personalised learning paths built on high-quality, publicly available content that serve as a solid starting point for growth.After acquiring the foundational knowledge these provide, further training courses are available — some concluding with an exam and certification. When you reach that stage, we are here to support you: we help you plan your next steps and navigate the options ahead.Assess your current knowledge, create a personalised learning path, get started on it, and track your progress continuously. Come back again and again, discover new learning materials, and build your professional competencies with intention.

Prompt Engineering vs. Context Engineering

Prompt engineering focuses on how we formulate our requests. Context engineering takes a broader approach: deliberately selecting, structuring, and managing the information available to the model.

An AI agent's context consists of much more than the user's prompt. It can include:

• Instructions: System-level and project-specific rules.
• History: Previous conversations, decisions, and saved state.
• Project materials: Code, files, and documentation.
• External information: Documents retrieved through RAG, tool definitions, and tool outputs.

Why Isn't More Context Always Better?

As an agent works on a longer task, more and more information accumulates in its context. Old decisions, already resolved issues, lengthy tool outputs, and irrelevant files can all end up in the context.

This can lead to context rot: a decline in model performance as the context grows and becomes cluttered with less relevant information. Important details can get buried in the noise.

The goal, therefore, isn't to give the model as much information as possible, but to provide the right information at the right time.

Four Ways to Manage Context

1. Record it: Store important decisions, known issues, and next steps in a structured format. For example, when working on a longer development task, maintain a short state summary describing the current progress.
2. Select it: Don't load every file and piece of documentation upfront. Retrieve information only when the agent actually needs it. This is also the principle behind the progressive loading of agent skills.
3. Compress it: Instead of preserving the entire conversation history, retain the relevant state. Summarize decisions, shorten lengthy tool outputs, and discard details that are no longer needed.
4. Isolate it: Run larger subtasks in separate contexts, for example using subagents. Only their results and key conclusions should return to the main agent, rather than the entire detailed workflow.

What Should You Focus On in Practice?

Good context has three important qualities: it is up to date, reliable, and well structured. It matters whether the model is working from an outdated assumption in a previous conversation or a current project instruction.

Modern AI development tools, such as Cursor, already handle much of context management automatically. Still, a lot depends on us: which files we provide to the agent, how we document important decisions, and when we start a new phase of work. When using AI through a simple chat interface, we need to pay even closer attention to these things.

The Key Takeaway

If an agent loses track of a task halfway through, the solution isn't necessarily a better prompt or a more powerful model. The problem might simply be poor context management.

It's worth trying different context management strategies on the same task and comparing three things: output quality, token usage, and latency. This can help reveal which approach delivers better results and at what cost.

Ultimately, context engineering isn't about making sure the model knows everything about a task. It's about making sure it has the information it needs, exactly when it needs it.

What is a skill?

A tidy, reusable package: expertise, instructions and a workflow for one kind of task. Anthropic published it as an open standard, so it works in more than one tool. A prompt is for one occasion; a skill is procedural knowledge you can take up again any time.

What is in it?

• SKILL.md: it starts with the skill's name and description. The agent decides from these when the skill is needed, so the description is the most important line. Then come the instructions, the steps and the decision logic.
• References, scripts, assets: detailed background, scripts, pictures. For a company slide template, for example, the logo, the colours and the layout rules.

Loaded step by step

A skill does not enter the context whole, which saves a lot of tokens:

1. At the start the agent sees only the name and the description.
2. When a task fits the description, it reads the body of SKILL.md. It can also be started by hand, with a command.
3. It loads the references and scripts only when a step needs them.

Practical advice

1. Start from your own experience: where you ran into the same problem 3 or 4 times and had to correct the AI again and again, a skill is worth writing.
2. Do not teach it what it already knows, such as the SOLID principles: that only wastes tokens.
3. Teach a procedure, not a specific answer: set down the steps and the habits of your own project.
4. Start small: a single SKILL.md file is already a working skill.

An example from Gergő

On his project, frequent rebasing caused many merge conflicts, and the agent would have resolved them right away by itself. His skill instead analyses the diff, sums up the conflict for the developer, and decides in favour of the protected branch so that no regression gets in. It explicitly forbids running git rebase --continue: carrying on is the developer's decision.

As sources, the talk recommended the Awesome Agent Skills collection and Supabase's SQL optimizer skill. And existing skills are worth reviewing from time to time, to see whether newer models still need them.

Why it matters

In AI integrations a surprising share of calls are decisions. A customer service system sorts every message, decides whether it is urgent and checks the outgoing reply. Today an LLM usually does this: it writes JSON that the program has to parse, check and ask for again when it is broken. At volume that is slow and expensive.

What is a decision model?

Jev gets typed questions about a text (which option, is it true, where on a scale) and answers all of them at once, in a single step, with probabilities. It does not write token by token like an LLM.

What we saw

• Sorting 40 tickets into 5 teams: the accuracy was practically the same (Jev 39/40, Gemini 3.5 Flash-Lite 39/40, Claude Haiku 4.5 40/40), but Jev finished in 6.5 s and Haiku in 19.4 s.
• For a million tickets the cost comes to about $18 against Haiku's $390.
• 50 questions in one call: Jev stayed at about 0.3 s throughout, the LLMs slowed down with every new question.
• In real time, in a game of Snake, Jev kept to a 350 ms deadline per move, while Haiku dropped out at 1 s.
• As a safety brake for an agent, all three models blocked the five dangerous steps; the checks took 6 s with Jev and 23 s with Haiku.

Where it falls short

Jev gives no reasons, is weaker at arithmetic and dates, takes text only, and for now is in limited early access. Where a decision has to be explained to a customer, an auditor or a colleague, an LLM is still needed.

The lesson

It pays to split an AI process into deciding steps and writing steps. In handling a support ticket, Jev sorted and checked, and Haiku only wrote the reply: a ticket went through in 2.83 s instead of 4.74 s, and 1,000 tickets cost $0.60 instead of $1.50.

The measurement was a single run on a small sample, so the numbers show a direction, not a benchmark. If you are planning your own system, measure it on your own data too.

If you are curious where you stand with AI tools, take our assessment: at the end you get a learning path that fits your level.