Using Awesomic as an example, I’ll show how I transitioned back from management to coding and essentially rebuilt the product from scratch on my own. It’s now a cloud-based platform for managing software factories and enabling collaboration between people and agents. I’ll share how I’m implementing this approach in a company with 100 employees: how processes and roles are changing, how to maintain control over the company’s data and accumulated knowledge, and how to avoid vendor lock-in. I’ll cover all of this using a real-world workflow as an example, with a live demo and my own agent skills—which I haven’t published anywhere else yet.

Create your own AI Second Brain — a personalized system that will help you organize information that’s usually scattered across notes, chats, documents, and to-do lists. During the workshop, you’ll build your first working version of the system step by step, which you’ll be able to use right after the session. Later on, you can scale it up and adapt it to your own work style. Together, we’ll set up key areas for your daily work: • Inbox — ideas, thoughts, and quick notes; • Work — tasks, meetings, follow-ups, and decisions; • Learning — books, courses, articles, and notes; • Personal Projects — personal projects and goals; • Decisions — analyzing options and making decisions; • Weekly Review — weekly review, reflection, and planning. Technical Requirements: • The workshop will be held in Claude; a Pro subscription is required • Prerequisites: Claude, Claude Code • The workshop will run on macOS, Linux, and Windows Bring your notes, tasks, ideas, or plans with you — by the end of the workshop, they’ll form the foundation of your personal AI system.

As a codebase grows, AI coding agents get more expensive and less reliable. Every session re-learns the architecture, conventions drift, and fixes break other fixes. The usual response is to switch to a bigger model, which raises the bill and leaves the cause in place. I went through this on my own product: from a frontend fully delegated to an agent and a bill of over $1,000 a month to a pipeline where the agent works from a spec instead of chat history. We'll cover: - how to move rules, knowledge and verification out of chat and into the repository, so sessions become disposable; - three attempts at an in-repo knowledge base, and why a stale doc is worse than no doc; - the pipeline from task to push, and why the spec matters more than the prompt; - why agent permissions must be enforced limits, not polite requests in a rules file, and why everything an agent reads is a potential instruction. At the end I'll share an open playbook with rules you can drop straight into your own repo.

When you build a product yourself alongside an AI agent, the code is no longer the bottleneck. The agent writes code quickly but makes mistakes with confidence: it cites laws that don’t exist or invents founders for the “About Us” page. I’ll share how I went from an idea in a bar to Jurly—a live, two-sided legal marketplace with AI-powered insights for clients and a workspace for lawyers—and what I had to build around the agent to make its “done” status trustworthy. Let’s break it down: - How one person at Claude Code takes a product from concept to launch: specs, TDD, dev reviews, AGENTS.md, and personal skills for verifying specs and code. - AI harness - Hallucinations in the product: a nonexistent law, a real article with fictional content, and a “pure hallucination” that even the automated check missed; how RAG, code-based citation verification, a critic, and a golden set reduce the risk. - The cost of this approach: accountability without a team, PII and security, the agent’s error log—and what worked and what didn’t. Key takeaway: An AI system is only as reliable as the checks surrounding it. An engineer’s role is shifting from writing code to designing these checks—from software engineer to product engineer.

What if an engineer weren’t the first to answer a typical on-call question? Superhuman’s platform team built an AI assistant that supports more than 25 teams and independently resolves 20% of their questions. I’ll explain how we turned it into a platform service and introduce AI Golden Path, an internal service that helps engineers use AI agents and handle common development and infrastructure tasks with ready-to-use tools and guided workflows. I’ll share how these services fit into our platform strategy, what we learned while earning teams’ trust, and what we plan to build next.

Once you get used to working with AI agents on your laptop, sooner or later you want them within reach 24/7. You can leave your work computer running, set up your own server, run an agent in the cloud, or use a ready-made option like a dot in ChatGPT or Grok Bot. I’ll share how a simple thought, “I could do this from my phone,” turned into a series of experiments across my work and personal projects. What we’ll cover - How much autonomy agents have in different setups while you’re away from your desk. - Approaches and tools for working from your phone, from tmux sessions to tools that bring multiple subscriptions together (T3 Code, Orca) and agents that can orchestrate projects on their own (Hermes and others). - Challenges with synchronization, working environments, reviewing results, and keeping your attention from getting scattered. - What worked for me, what I gave up, and why.

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.