A language model is fluent, and sometimes it is wrong and sure. In a chat that costs one bad answer. In an agent with a memory it costs more: the agent stores the mistake, reasons from it, and repeats it tomorrow. Retrieval cannot tell which of two contradictory notes is right, and a second model asked to judge only predicts a plausible verdict. The fix is not new. Before deep learning, expert systems such as MYCIN and XCON kept knowledge as rules, applied them the same way every time, and answered "why?" and "how?". They failed at one thing: getting knowledge in, because every rule was typed by hand. LLMs are very good at exactly that. Neurosymbolic AI puts the two halves back together. The talk follows that reunion through one running example: an assistant whose LLM "remembers" a meeting in Berlin while its calendar has the same person in Lisbon at the same hour. We cover deduction, induction and abduction, and why LLMs are good at the last; reasoning over a knowledge graph with Prolog and Datalog; and why higher-order logic programming (λProlog) fits agents well, with types that reject malformed LLM output, relations as values, scoped what-if assumptions, rules about rules, and proofs that a small kernel can check. We end with a working agent whose LLM writes λProlog behind six guards, and with honest numbers on what the logic layer catches and what it cannot. For AI and agent engineers who know Python and LLMs. No background in logic or mathematics is assumed.

An AI agent knows only what you show it — and it won’t suggest a solution you don’t know exists. On top of that, it forgets everything between chats. This talk explains what knowledge a human needs so the agent can work at full power, and how to build memory for it: from local files to shared memory via an MCP server. You’ll learn: — why agents miss obvious solutions and how to fix it — the memory bank pattern and a ready-to-use file structure — the levels of agent memory: chats, local files, Obsidian, git, MCP memory server — practical rules for keeping agent memory up to date

Why the Future of Automation Lies Not in the Number of Developers, but in the Accessibility of AI Agents Traditional automation requires time, budget, and the involvement of IT teams. But what if every employee could automate their own processes independently? Agentic Workforce is transforming the very principle of how work is organized. People set goals, agents perform tasks, and the platform provides the tools, access, security, and control. I’ll share our experience building and implementing the Agentic Workforce product in an enterprise organization, the architecture of the agent platform, managing digital agents, and how we envision the transformation of corporate automation.

Ambition for 2026 was to boost team's performance by 15-20%... we made 30-50%. AI-assisted SDLC has been converted into AI-based SDLC where people work together with agents with clear responsibility separation: humans - for sense and control, agents - for routine. We use "human-in-the-loop" approach and experiment with agent loops. Can we treat that as an "AI software factory"? Let's think about together... I will show how we work based on one of our biggest solution consisting of 152 projects with 2.5 mln lines of source code and 18.7 mln of tokens to describe shared context. How do we support it? How do we overcome context window size limits? See you on the meeting!

In the agentic-first era, we’ll bring all your project data together in one place and give agents access to it. We’ll discuss the problems this would solve, how to collect and validate the data, and how to keep it up to date. And also you will see how this approach will change the way your team works.

Why do some teams speed up with the same AI tools while others drown in slop? We'll go through common anti-patterns of working with AI agents in development, from "generate everything at once" to blind trust in the output, what they lead to in practice, and what to do instead.

As the classic once said, “life should be interesting.” Especially in interesting times. And especially when AI barges into our cozy little bubble uninvited and starts threatening to take our jobs. But if you can’t beat them, lead them. So I decided to be the first to voluntarily give AI some of my work. Well, not exactly give it away — more like pass on the honorable title of React monkey. Somewhere along the way, though, I got carried away and ended up building an entire troop of AIpes, each with (almost) clearly defined roles, (almost) well-defined responsibilities and constraints, and the ability to handle my tasks with (almost) a single command. That’s what I want to talk about: how a simple idea of making an LLM write routine code turned into a whole team of specialized agents; how I built my own agent harness in Claude Code; what worked, what broke, and what workarounds I had to invent along the way. And finally, what training my AIpes taught me about models, prompts, and why adding “pwetty pwease” to your prompt still won’t make a rule actually bind.

If your development process looks like “I write a prompt in Claude Code, and then we get the job done using my favorite set of skills”—then you’re a year and a half behind the times, which, in our AI reality, is an eternity. Nowadays, graphs and self-improving loops are all the rage—you define a task, and it’s broken down into 100,500 separate blocks, each of which is simple, produces a measurable result, and is therefore easy to manage and improve. Sounds perfect? Yes—until you get tired of a simple task taking an hour and a half, or until you start calculating how much it costs (in money or tokens—it doesn’t matter). Over the past six months, I’ve built six such factories as a consultant—all following the same blueprint—but now, with every new client, I start a long conversation explaining that you most likely either don’t need this approach, or you do—but in a different way. We’ll touch on three aspects—technological, economic, and cultural—to explain where the problems actually arise and why I no longer consider the “dark software factory” in its graph-and-block form to be a silver bullet for everyone.

A few years ago, we started building Architecture as Code with a fairly simple goal: make architectural knowledge accessible, up to date, and understandable for engineers. C4 diagrams, ADRs, OpenAPI specifications, ERDs, ownership, and other documentation gradually moved closer to the codebase, becoming version-controlled and machine-readable. We built it for humans. Then AI agents arrived. And unexpectedly, we discovered that one of the hardest parts of working with AI — transferring enough system context to an agent — had already been largely solved. In this talk, we’ll explore why repository access alone is not enough, how code context differs from system context, and how Architecture as Code naturally evolves into Context Engineering. Using practical examples, we’ll look at the context an AI agent needs to do more than just write code: understanding domains, architectural decisions, API contracts, ownership, and system constraints. We’ll also discuss the next challenge: ensuring that the context AI relies on actually reflects the real state of the system.

Building an AI agent is only half the job. The real challenge is knowing whether it performs reliably and continues to meet expectations as models, prompts, tools, and data evolve. In this session, we’ll use a practical example to show how to build effective Evals for AI agents: creating representative test cases, defining meaningful quality criteria and metrics, combining automated checks with LLM-as-a-Judge and human evaluation, comparing different agent versions, and making Evals a core part of the development and testing lifecycle.