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

We built self-aware infrastructure: a system with memory, classifiers, Jev-style decision models, evals and agents that triage what is happening in infrastructure. Most agent deployments are either stateless request handlers or one shared agent that serves everyone. For autonomous triage agents and team experiments we wanted something different. Each team or engineer gets their own always-on agent, a "spot". It remembers their scope, keeps working after they hang up, and is there when they come back. You can ask by voice for "an RCA for each issue from last week", close the session, and find the work finished hours later. This talk covers how we built ttps://triageagent.dev What attendees will take away: 1. Where we started. Oour experiment environment for running agents at scale, built on kagent, agentgateway, ego and substrate. 2. What we got - Triage spots. A live use case for an always-on agent lifecycle: one agent per user, woken by events, with its own memory and quota. 3. An honest list of what we got wrong. The story behind the case: Instead of filing platform tickets and approvals, we introduced sandboxed environment to our teams to reduces the blast radius of untrusted or experimental code on shared clusters at scale. This approach gives a concrete, open example of building a developer-facing portal on top of agent substrate, including the triageagent - winner of India National Awards AI Gamechanger 2026.

Software engineering is moving from agents that help write code to autonomous systems that take an approved requirement, write the code and verify the result with little human supervision: software factories. The approach is new, yet OpenAI, Anthropic, Stripe, Uber and others have already described theirs publicly. Each company tells its own story, but the same principles run through them: what a factory may build, how it proves the result is correct, how far its agents can be trusted, and how it keeps paying off. This talk walks through these principles and why each one is needed, drawing on those public write-ups and on the factories I build at Dev AI Consulting. The measure of success throughout: a factory whose “done” you can trust.

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.

Every new cloud provider a company adopts usually means another set of Terraform configurations, another deployment guide, and yet another way of doing things. Costs start growing faster than the number of providers. Platform engineering helps break this dependency: the golden path becomes the interface, while the specific cloud becomes just an implementation detail. A developer describes what they need — a service and a production database — and the platform decides how that should be provisioned in a hyperscaler versus a local cloud provider. In the live demo, a developer creates a new service through a self-service portal. One template, one Kubernetes manifest — and the application is deployed to two clouds at the same time. The same PostgreSQL request becomes a managed database service in one cloud and an operator-managed database running in Kubernetes in another. We’ll also look at the limits of this approach. IAM, storage, and backups are not completely hidden by the abstraction layer — and I’ll explain why that is actually a good thing. After the talk, you’ll understand how the “request → composition” pattern works for databases across different clouds, how to start building your first golden path without creating your own PaaS, and which differences between cloud providers should remain visible to developers.

Deploying and Optimizing LLM Inference in Production on GPUs Ranging from L4 to 4xH200: Choosing Inference Engines and Configurations, Balancing Throughput, Latency, and Cost, and How to “Squeeze” the Most Out of Your Hardware and Avoid Common Tuning Mistakes