Marc Arndt's Speaker Profile @ Sessionize

Agentic AI in Go

An agent is a loop, a handful of tools, and a lot of ordinary engineering discipline. Go happens to be very good at all three. No Python in the stack, and no time spent arguing about it.

This is a code-first walk through a complete agentic application written in Go. It ingests a user's documents, OCRs whatever isn't already text, indexes them, and answers questions over that material. It compiles in under 60 seconds, ships as a ~20MB static binary, runs in around 20MB of memory, and scales horizontally without anyone having to think hard about it.

We build it from the inside out, in idiomatic Go:

- The agent loop: plain control flow over a typed message history, with context.Context threaded through so cancellation and timeouts actually work
- Tools as interfaces: one small interface, JSON schemas derived from your types, a dispatch table, and compile-time safety over everything the model is allowed to call
- Streaming: token and event streams as channels, fanned out to callers without leaking goroutines
- Concurrency where it earns its keep: parallel ingestion and OCR with errgroup, bounded worker pools, and backpressure against a rate-limited API
- State and retrieval: conversation history and document index behind interfaces, as data you can inspect, diff and replay
- Testing: recorded model responses, table-driven tests over agent behaviour, and how to assert on something non-deterministic
- Failure modes: retries, partial tool failures, malformed model output, and the ones that only show up under load

Along the way, the things that actually bit us in production: schema drift between tool definitions and their handlers, prompt assembly degenerating into string soup, and why the boring observability work matters more than which model you picked.

Not a slide deck about AI. A working system, with the code on screen.

Takeaways

- A concrete architecture for agentic applications in Go, end to end
- How Go primitives (interfaces, channels, context, errgroup) map onto agent orchestration
- Patterns for tool definition and dispatch that stay type-safe as the tool set grows
- How to test and observe something that is non-deterministic by design
- The operational payoff: small binaries, small memory, fast builds, cheap horizontal scale

Preferred duration: 45 minutes including Q&A. Can be delivered in 30 or 60 minutes on request.

Target audience: Go developers, intermediate to advanced. Fluency in Go is assumed; no AI or machine learning background required.

Technical requirements: my own laptop (USB-C / HDMI) and internet access for the live demo. A recorded fallback of the demo is always available.

Previous delivery: accepted at WeAreDevelopers World Congress 2026 - Europe.

Related sessions: I also speak on this material in a language-agnostic form. This session is the Go-native deep dive, aimed specifically at a Go audience.

You Don't Need a Python Team to Build Great Agentic AI

Every AI initiative seems to start with the same assumption: we need to hire Python developers. New job specs, new budget, new team — while the engineers who have shipped and operated your production systems for the last decade are quietly told this one isn't for them.

That assumption is slow, expensive, and wrong.

Shipping a production agent is a systems problem, not a machine learning problem. The model sits behind an HTTP API. Everything on your side of that boundary is work your team already does well: structured data, retries and timeouts, concurrency, state, queues, authorisation, observability, and deployment. The hard parts of agentic AI are the parts your people have been solving for years — nobody has told them that yet.

In this session we build the case from the code up. I'll walk through a real agentic application and show how small the genuinely AI-specific surface actually is: an agent loop is a few hundred lines of ordinary control flow, tool calling is a JSON schema and a dispatch table, memory is data modelling, retrieval is search, and evaluation is testing with a fuzzier assert. We'll see the same patterns expressed in Go, C#, Java and TypeScript, because they are not language features — they are architecture. With a live demo, running on the stack it was written in.

I'll also be straight about where Python genuinely wins — training, fine-tuning, notebooks, the data science ecosystem — and how to tell whether you are actually doing that work or just assuming you have to.

For leaders: your AI capability gap is probably not a hiring problem. For engineers: you are already qualified.

Takeaways

- Why agentic AI is an integration and systems problem, not an ML one
- The anatomy of an agent loop, tool calling, memory and retrieval, in plain engineering terms and independent of language
- How to map those patterns onto the stack and skills your team already has
- An honest boundary: what Python is genuinely better at, and how to recognise when you really need it
- What to do on Monday morning instead of opening a requisition

Preferred duration: 45 minutes including Q&A. Can be delivered in 30 or 60 minutes on request.

Target audience: engineering leaders, architects and senior developers who are starting or evaluating AI initiatives. No machine learning background required.

Level: intermediate.

Technical requirements: my own laptop (USB-C / HDMI) and internet access for the live demo. A recorded fallback of the demo is always available.

Related delivery: a Go-specific version of this material, "How to write great agentic AI without python", has been accepted at {dev.talk} 2026. This session is the language-agnostic evolution of it, aimed at a broader audience.

From Zero to Shipping AI With the Team You Already Have

Our engineering organisation had no AI capability, no machine learning engineers, and a roadmap that had started to assume both. We did not go and hire an AI team. We turned the team we had into one.

This is an honest account of how that went: what worked, what wasted a quarter, and what I would refuse to repeat.

We will spend the time on mechanics rather than motivation. How to find who in your organisation actually wants this, which is rarely who you expect. How much delivery capacity you have to give up, and where to take it from without lying to yourself about it. Why handing everyone a training budget produces nothing. How to sequence the first three projects so the organisation learns something, instead of shipping one impressive thing that only its author understands.

Then the harder parts. The senior engineer who quietly thinks it is all hype, and is sometimes right. The prototype that demos beautifully and cannot be operated. The governance conversation you will lose if you start it late. The moment leadership assumes the second AI feature will take a tenth of the time the first one did.

Presented from the seat where those tradeoffs land. I am a VP of Engineering who still reads the pull requests, so this is decisions, costs and outcomes rather than maturity models and transformation frameworks.

Takeaways

- A sequencing model for the first AI projects that builds capability instead of debt
- How to find and fund internal capacity honestly, including what you stop doing
- The recognisable patterns of resistance, and which of them are legitimate signal
- Where to put governance, security and legal so they accelerate you rather than block you
- Realistic timelines from first experiment to something on-call can actually support

Preferred duration: 45 minutes including Q&A. Can be delivered in 30 or 60 minutes on request.

Target audience: engineering leaders, engineering managers, architects and tech leads. Also useful for senior individual contributors who are being asked to lead an AI initiative. No machine learning background required.

Level: leadership and organisational. Very little code in this session.

Technical requirements: my own laptop (USB-C / HDMI).

First public delivery: not yet delivered.

Agents in the Brownfield: Wiring an LLM Into a Twenty-Year-Old Estate

Every agent demo talks to a clean REST API with an OpenAPI spec. Then you go to work, where the system of record is a SOAP service documented in a Word file from 2011, the business logic lives in stored procedures, and the one machine nobody dares redeploy is also the one that owns your customer data.

This talk is about that estate, because that is where the value actually is.

We will work through how to give an agent useful, bounded access to legacy systems. Wrapping hostile interfaces in tools a model can reason about. Deciding what an agent may write versus only read. Where to put the seam so that a model failure cannot corrupt a system you cannot roll back. We will look at the anti-corruption layer as a tool boundary rather than a new microservice, at idempotency and compensating actions for calls that cannot safely be retried, and at how to present a forty-field record descended from a mainframe schema so that a model does not hallucinate its way through it.

Then the part that decides whether any of it ships: the team that owns the legacy system did not ask for your agent, and has good reasons to be nervous. How to get access, what to promise, what to never promise, and what a proper audit trail buys you in that argument.

Twenty years of corporate development, eight of them dragging systems onto Kubernetes. The examples are real and the scars are mine.

Takeaways

- A tool-boundary pattern for exposing legacy systems to agents without rewriting them
- Read and write authority models, and how to keep destructive operations behind a human
- Handling non-idempotent and non-retryable operations inside an agent loop
- Data shaping: making gnarly enterprise records legible to a model
- How to negotiate access with the teams who own the systems you need

Preferred duration: 45 minutes including Q&A. Can be delivered in 30 or 60 minutes on request.

Target audience: architects, senior and staff engineers, and integration engineers working in established enterprises rather than greenfield startups. No machine learning background required.

Level: intermediate to advanced.

Language: the patterns are language-agnostic; code examples are in Go.

Technical requirements: my own laptop (USB-C / HDMI) and internet access for the live demo. A recorded fallback is always available.

First public delivery: not yet delivered.

How Do You Know It Works? Testing Agents That Refuse to Be Deterministic

Your entire test pyramid rests on a promise agents do not keep: same input, same output. So how do you ship something you cannot assert on, and how do you tell an auditor, a customer, or your own on-call engineer that it works?

This is the question every enterprise asks second, and almost no conference answers.

We will build a strategy in layers. Deterministic first: record model responses and test your orchestration like ordinary software, because most of your bugs are in the plumbing rather than the model. Then behavioural: table-driven cases over what the agent decided and which tools it reached for, asserting on the shape of the action rather than the wording of the prose. Then evaluation sets: how to build one from real traffic without creating a data protection incident, how large it has to be before the number means anything, and how to decide what score is good enough to ship.

Then the uncomfortable part. Your most important dependency is a model that can change underneath you without a version bump, so regression detection is not optional and cannot be manual.

Finally, production. Trace-level observability across multi-step runs, telling a bad answer apart from a broken tool, sampling for human review at a cost you can defend, and which metrics actually predict user complaints. Plus the honest limits: what you cannot test, and how to design a system whose worst case is acceptable rather than one whose average case is impressive.

Takeaways

- A layered strategy: deterministic orchestration tests, behavioural assertions, evaluation sets
- Building an evaluation set from production traffic without a data protection problem
- Detecting regressions when the model is an unversioned dependency
- Observability and alerting for multi-step agent runs
- Designing for an acceptable worst case instead of an impressive average

Preferred duration: 45 minutes including Q&A. Can be delivered in 30 or 60 minutes on request.

Target audience: senior developers, architects, QA and test engineers, and platform teams responsible for AI features in production. No machine learning background required.

Level: intermediate.

Language: the patterns are language-agnostic; code examples are in Go.

Technical requirements: my own laptop (USB-C / HDMI) and internet access for the live demo. A recorded fallback is always available.

First public delivery: not yet delivered.

Compliance Is an Architecture Problem: Agentic AI Under the EU AI Act

Regulation arrives as a document and lands as a design constraint. If you are building agents that touch European customers, personal data, or decisions with consequences, then the AI Act and the GDPR do not belong at the end of your delivery pipeline. They belong on your architecture diagram.

This session translates obligation into engineering.

Where does data actually go when you call a hosted model, and what does that mean for residency and for your processor agreements? What does meaningful human oversight look like expressed as code, rather than as a sentence in a policy document? How do you explain a decision that emerged from eleven tool calls and four model invocations, months later, to somebody who is neither technical nor friendly? What has to be logged, for how long, and how do you log enough to defend a decision without quietly building a surveillance archive of your own users?

We will work through concrete patterns. Risk tiering that determines architecture rather than paperwork. Audit trails as first-class domain objects instead of log lines. Human oversight modelled as a state machine rather than bolted on as a confirmation dialog. Data minimisation enforced at the prompt boundary. And what genuinely changes when you move from a hosted model to one you run yourself, including the parts that get harder.

I am an engineer and not a lawyer, and I will be clear about that line throughout. This is about the architecture that makes compliance achievable, not legal advice.

Takeaways

- Turning regulatory obligations into concrete architectural requirements
- Audit trail and traceability design for multi-step agent runs
- Human oversight as a designed system state rather than a user interface afterthought
- Data residency and minimisation decisions at the model boundary
- How to open this conversation with legal early enough that it speeds you up

Preferred duration: 45 minutes including Q&A. Can be delivered in 30 or 60 minutes on request.

Target audience: architects, engineering leaders, and platform or security engineers building AI features for European markets or regulated industries. No legal background required.

Level: intermediate.

Note: presented from an engineering perspective. I am not a lawyer and the session does not offer legal advice; it covers the architecture and engineering practices that make compliance achievable.

Technical requirements: my own laptop (USB-C / HDMI).

First public delivery: not yet delivered.

The Agentic Features We Killed

Every conference talk about AI ends with something working. This one is about the things that did not, and what they cost us before we were willing to admit it.

A tour of features that demoed beautifully and then died. The ones where accuracy plateaued just below useful. The ones whose token bill scaled faster than the value they created. The ones that worked perfectly until real users held them the wrong way round. And the one where the honest answer turned out to be a database query and an afternoon of work.

Each gets the same treatment: what we built, why it looked right at the time, what the first real signal was that it was not, how long we took to accept that signal, and what I would check first now. That includes the failures that were our own fault, through bad framing, missing evaluation, or a prompt that nobody owned, and the ones that were simply the wrong shape for the technology.

Then the part that is actually useful to you: the questions we now ask before starting anything. What is the cost per successful outcome, rather than per call. What level of accuracy would make this worth having, and is that plausible. What does this look like when it is wrong, and who finds out. What is the boring solution, and why exactly is it not enough.

No vendor pitch and no redemption arc where it all works out at the end. Some of it did not work, and finding that out early is worth more than another success story.

Takeaways

- A pre-mortem checklist for agentic features, drawn from real failures
- Cost per successful outcome as a design metric, and how it changes decisions
- Early warning signs that an accuracy ceiling sits below your usefulness threshold
- How to kill a project with the organisation's goodwill intact
- The cases where the boring non-AI solution is still the right answer

Preferred duration: 45 minutes including Q&A. Also works well as a 30 minute session or a 20 minute keynote-style slot.

Target audience: engineers, architects and engineering leaders working on AI features. Accessible to a mixed audience; very little code.

Level: all levels.

Technical requirements: my own laptop (USB-C / HDMI).

First public delivery: not yet delivered.

Documents Are Harder Than Models

The model is the easy part. The hard part arrives as a 340 page scanned PDF, rotated ninety degrees, in two languages, containing a table that spans eleven pages and a signature sitting directly on top of the number that matters.

This is a deep dive into the unglamorous work behind every document-answering agent: getting real enterprise files into a state where retrieval and reasoning can do anything useful at all.

We will cover ingestion of formats nobody chose, and OCR quality as the upstream determinant of everything downstream. Why layout is semantics: a number in a table cell means something different from the same number in a paragraph, and flattening a document to plain text throws that distinction away for good. Chunking strategies that survive real documents rather than blog-post documents. Tables, forms and multilingual corpora. And what to do about the small percentage of files that will never parse cleanly, because there will always be some.

On the retrieval side: why naive vector search underperforms on structured business documents, where hybrid approaches earn their complexity, metadata as a first-class retrieval signal, and citation back to a page and a region so that a human can verify the answer. For most enterprise use cases that verifiability is not a nice extra, it is the actual requirement.

Built and operated in production, on documents I did not get to choose. Live demo, with genuinely awful inputs.

Takeaways

- An ingestion pipeline for messy real-world enterprise documents
- Why OCR and layout extraction quality dominates final answer quality
- Chunking and table handling strategies that hold up on real files
- Retrieval tuning for structured business documents, beyond naive vector search
- Verifiable citation: getting an answer back to a page, a region and a source

Preferred duration: 45 minutes including Q&A. Can be delivered in 30 or 60 minutes on request.

Target audience: engineers and architects building retrieval or document processing systems. No machine learning background required.

Level: intermediate.

Language: the patterns are language-agnostic; code examples are in Go.

Technical requirements: my own laptop (USB-C / HDMI) and internet access for the live demo. A recorded fallback is always available.

First public delivery: not yet delivered.

Speaker

Marc Arndt

Actions

Links

Area of Expertise

Topics

Sessions