Using Awesomic as an example, I'll show how I went from CEO to CEO as the company's main developer, and rebuilt most of the product from scratch myself. 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. Technical Requirements: • Each participant will receive their own Cloud VM in a cloud environment prepared for the workshop. Awesomic will cover the cost • Participants need their own Claude or Codex subscription

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.

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.

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.

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.

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.

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.

Agentic engineering is maturing. We are moving beyond “ask an agent to write some code” toward factories — pipelines where a team of AI agents takes a project through the entire lifecycle: requirements → specifications → tests → implementation → adversarial review → quality evidence. In this talk, we’ll break down what such a factory actually consists of: an orchestrator and specialized sub-agents, deterministic quality gates, end-to-end traceability from requirements to tests, and verification loops that replace “it seems to work” with measurable evidence. The main challenge of autonomous development is not getting agents to write code. It is preventing the factory from confidently reporting success when the result is actually wrong. We’ll examine common mechanisms of pipeline self-deception: “soft” rules in prompts that disappear under the pressure of a real-world project; checks that silently pass when required evidence is missing; and requirements whose acceptance criteria were never implemented as executable checks. I’ll illustrate these problems with real-world artifacts, including a case where the factory passed every gate “green” yet produced a product that failed to meet a key requirement — and what it took to make the exact same run correctly turn red. A separate part of the talk will focus on self-improvement: how to build a loop where every discovered failure becomes a new gate that future projects can no longer bypass. We’ll cover three-state verification semantics (PASS / NOT-EARNED / FAIL), a process-defect registry, and a library of lessons inherited by every new project. Everything will be grounded in real artifacts: commits, metrics, and measurable results. What we’ll cover: • Anatomy of an agentic factory: orchestrator, sub-agents, deterministic gates, and end-to-end traceability • Pipeline self-deception mechanisms — and the forensics of a real “false done” • Maker ≠ checker in practice: adversarial review that actually catches defects • The self-improvement loop: correction → retrospective → new gate → lesson for the next project • What it costs: tokens, time, and where the factory still loses to humans Who is this talk for? Engineers and tech leads who already use AI agents in software development and want to move from “it works sometimes” to a predictable, evidence-driven engineering pipeline with verifiable quality.

What tasks should be delegated to AI right now, and what still requires human intervention? Using a streaming product as an example, we’ll discuss how AI copilots can help QA teams streamline technical routines, scale testing, accelerate releases, and free up time for people to focus on product research, UX, and complex user scenarios