My Path into AI/ML Engineering: Learning Towards MAKEathon 2026

01 · Why I am exploring this

My software development background is about turning requirements into working applications. With AI Agents, I am increasingly interested in what comes after a convincing demo: When does an agent actually help? How reliably does it use tools? How can I tell whether a change improves the system?

I want to deepen my knowledge of AI/ML engineering: integrating models into software, understanding data and interfaces, analysing failures and evaluating results systematically. A working prototype is a starting point. My goal is to explain how it behaves and where its limits are.

02 · The starting point: MAKEathon and Apertus

MAKE stands for Machine leArning and Knowledge Engineering. The event connects machine learning with explicit domain knowledge. It takes place on 24–25 October 2026 at FHNW Campus Olten. MAKEathon event information

My personal learning plan for Challenge 4 focuses on a small agent producing structured decisions, evaluated through a reproducible experiment. I also want to explore Apertus, an open Swiss language model. Apertus overview and documentation

I want to understand what the model contributes to a concrete workflow and which tasks are better handled by conventional software. I will record the model version, runtime environment and configuration when I run the first experiment.

03 · My learning path: Small steps towards an experiment

My planned sequence is LLM basics → structured outputs → tool calling → agent → evaluation → Apertus. I plan roughly 60–90 minutes per session. These dates describe intentions; I will record completed work in the learning log.

Planned dates	Focus	Concrete output
4–6 October	Tokens, context, inference and prompting	One model call and observed prompt differences
7–9 October	JSON Schema and validation	A structured output with allowed values and error checks
10–12 October	Tool calling and interfaces	Two small tools with defined parameters
13–15 October	Workflow, state and stopping conditions	A small agent with bounded steps and error handling
16–18 October	Baseline and evaluation	20–30 synthetic test cases with expected outcomes
19–21 October	Integrating Apertus	The same test run with recorded model configuration
22–23 October	Preparing the experiment and demo	Repository, hypothesis, measurement plan and short demonstration

Current progress: still to be recorded in the learning log. If a stage takes longer, I will reduce the experiment’s scope.

04 · A small use case instead of a large platform

My working idea for preparation is a synthetic decision workflow: classify a fictional expense request as approve, reject or manual_review using predefined rules. It is a manageable learning example with artificial data. The final MAKEathon use case remains a team decision.

The agent could use two tools: one to retrieve the request details and another to retrieve the applicable rules. The application executes the tools, validates their parameters and checks the final output. Missing or contradictory information will be included deliberately in the tests.

The first version should make one workflow understandable. Where appropriate, a rule-based implementation will provide an additional comparison: if simple rules already solve the task, an agent needs to demonstrate a meaningful benefit.

05 · My technical hypothesis

Open hypothesis: A bounded agent with clear tool schemas and validated output can apply the use case’s rules more reliably than a single model call. The comparison must show whether any improvement justifies the added complexity and runtime.

I separate three responsibilities. The model proposes tool calls and a decision. The application controls parameters, execution and stopping conditions. The output schema defines what downstream software accepts. Valid JSON alone does not establish that a decision is correct.

The provisional schema contains decision, reason and optionally a model-reported confidence. Without calibration, I will not treat that self-assessment as a reliable probability. Tool results should be processed as data and should not override the workflow’s instructions.

To record before testing: schema version, allowed tools, maximum steps, error handling and criteria for manual_review.

06 · Evaluation: What I want to measure

I plan 20–30 synthetic cases with expected decisions defined in advance. They will include straightforward cases, missing information, contradictions and tool failures. Cases used to adjust the prompt will be separate from the final evaluation cases.

For a fair comparison, the baseline and agent receive the same available facts and domain rules. The baseline gets the data directly in its prompt; the agent can retrieve it through tools. I will keep the model, configuration and final schema as consistent as possible. Switching to Apertus will be evaluated separately.

Metric	Question
Correct decisions / assessable cases	Does the output match the predefined expectation?
Valid outputs / all cases	Does it respect the schema and allowed values?
Correct tool calls / assessed calls	Are tool selection and parameters appropriate?
p50 and p95 runtime	How fast is a typical run, and how slow are the longer runs?
Failures and stopped runs	Where does the workflow fail, and can it recover predictably?

I will record the model version, prompt, dataset, hardware or service, repetitions and measurement method. A small test provides initial evidence, not proof of general reliability.

07 · Learning log: What I have tried

Status: ongoing · No experiment results recorded yet.

I will keep a short record of each learning session, including attempts that did not work.

Entry · [Add date and topic]

• Goal: Which question did I want to answer?
• Setup: Model and version, prompt, schema, tools and test case.
• Observation: What actually happened? Add an output, screenshot or log.
• Failure or surprise: What differed from my expectation?
• Learning: What conclusion does the evidence support?
• Next step: Which single change will I test next?

Space for images: Later, this block can hold tool-call screenshots, a small workflow diagram or two outputs for comparison. Related images can be presented as a slider.

08 · 24–25 October: The team experiment

Status: to be completed after MAKEathon. The event is scheduled for 24–25 October 2026 in Olten. My preparation should help me ask focused questions and contribute a small, testable piece of work.

After the weekend, I will document:

• Our task: Which use case did we choose, and why?
• My role: Which parts did I implement or investigate?
• Our approach: What did we keep or change from the preparation?
• Collaboration: Which domain feedback improved the experiment?
• Demo and artefacts: Repository, workflow diagram and actual prototype status.

Space for images: A photo of the work or a demo screenshot can accompany the account later. I will describe results and team contributions after the event.

09 · Results: Baseline versus our approach

Status: not measured yet. I will fill this table after reproducible test runs, recording the number of cases and repetitions for each variant. Percentages without those denominators would be difficult to interpret.

Variant	Model / version	Cases	Correct decisions	Valid outputs	Correct tool calls	p50 / p95 runtime
Single model call	Open	Open	Not measured	Not measured	Not applicable	Not measured
Agent with tools	Open	Open	Not measured	Not measured	Not measured	Not measured
Apertus variant	Open	Open	Not measured	Not measured	If used	Not measured

Where useful, I will add a rule-based baseline. Alongside the numbers, I will show at least one successful and one failed case, distinguishing changes to tool access, the prompt, the model or other parts of the system.

Open analysis: What improved? What runtime or complexity did it add? Which conclusions does the test support, and which does it not?

10 · Limits, mistakes and the next iteration

Status: to be completed after the first experiments. I want to understand failure causes as well as collect convincing outputs. A wrong decision might stem from missing data, unclear rules, an unsuitable prompt or an incorrect tool call.

Failure case · [Add example]

• Expected and actual output: What should have happened, and what happened?
• Suspected cause: What is my explanation, and what evidence is still missing?
• Change: Which single component will I adjust?
• Retest: Does the change also help on previously unused cases?

A small synthetic example only partially represents real workflows. The final account should make that limitation visible. Fine-tuning is a possible further learning direction; first, I want to understand which problems can be solved through better data, clearer interfaces, prompts or conventional program logic.

11 · What matters in the end

This project is one step towards AI/ML engineering. My goal is to build a small workflow myself, measure its results and explain when an agent is useful. A demo full of AI terminology is less valuable to me than that understanding.

After the experiment, I will answer three questions here: What do I understand better? What can I support with evidence? What do I want to learn next? Those answers will shape the next step, such as deeper evaluation, a better dataset or a focused model-adaptation experiment.

Basis and context

These chapters follow my personal learning plan, “MAKEathon 2026 – Challenge 4”, for preparation from 4–23 October. I will distinguish planned work, observations and measured outcomes. The cover is an AI-created illustration of the learning path. Photos, screenshots and diagrams from the actual experiment will be added later.