Running a Company on a Multi Agent Dispatch System | Paul Domanski

The transcripts are edited for clarity, sometimes with AI. If you notice any incorrect information, let us know.

Welcome and Showcasing Demox

Alexey: Hi everyone, welcome to our event. This event is brought to you by DataTalks Club. There are some links in the description. Go click these links and join our community. Subscribe to our YouTube channel and like the video. There is also a pinned link in the live chat. Click on that link and use it for asking questions. Paul wanted to show us something. This is going to be exclusive because this is not going to be in our recorded audio only podcast. I am really curious what Paul is going to show us. (0:00)

Paul: The main reason you reached out to me originally was because of the Headroom repo that I put together. (0:33)

Alexey: This was born out of a post you made where you shared a screenshot on Twitter. You had multiple accounts of Claude with different usage limits. I think it was one of your projects and I wondered why you needed so many Claude sessions. Here we are talking about this, so please show us more. (0:45)

Paul: It started with just the usage monitor and the account rotator, which I called Headroom. It was essentially just a way to automatically rotate accounts. Can you see my screen? (1:15)

Alexey: Yes. How many accounts do you have? (1:33)

Paul: Right now I am using six Claude accounts, all max 20x. I also have two Codex accounts which I am using. The whole reason why I started building this multiplexer, which I call Demox, is that it essentially lives on top of Ghosty and CMAX. I wanted a connected hub where I could manage all of my agents, almost like an agentic operating system that does everything in one place. Instead of having Claude Code living in different windows and browser use in another, I wanted a unified layout that worked for my specific style of work. (1:34)

Paul: As you can see here, I can rotate between accounts manually or I can lock accounts for certain jobs. I have all of my projects along the left, my own work over here, and I am building onto this within Demox. There were just a lot of little things that were not perfect for me when working with agents with multiple different surfaces. I feel like we are in this age of malleable software now where you can build whatever you want to fit your specific needs, workflows, and tastes. (2:17)

Paul: I went ahead with this, and as usual with AI projects, it started off as a simple idea and then expanded into something much bigger that is now taking up a lot of my time. This is still obviously being worked on, but the goal is to have a detachable chat interface with a browser. It will essentially become a browser within it as well. I want to replace my entire use of agent management and browser within my own little ecosystem. (2:52)

Paul: Obviously, all of the agents communicate with each other and are working autonomously all the time. I thought that would be a good way to kick things off because it shows how quickly things move from my tweet about Headroom towards something that is a lot more robust. (3:30)

Alexey: Demox and CMAX sound suspiciously similar to tmux. Is it a coincidence or what are these things? (3:47)

Paul: Terminal multiplexers are essentially running on your computer. Instead of running a terminal directly on my Mac, these tmux panes are enduring. They can run by themselves if my laptop is closed or if I am offline. Nothing is interrupted unless it is reliant on my local tunnel, which it can also do. (3:54)

Paul: There is a tunnel that runs directly onto my Mac so it can work with my Mac directly. It is essentially just a way to keep my agents working autonomously over long periods of time. All of these are actually mounted within tmux as instances. They automatically boot up as soon as I open Demox. (4:22)

Alexey: What are CMAX and Demox? (4:50)

Paul: This is where it came from. CMAX is just a very clean, nice multiplexer. It also allows you to open tabs and split your panes. You can have multiple windows, and one of them can be a browser for example. This is a very bare bones version. (4:55)

Paul: A lot of what I wanted was to have my own customized look and feel about it. Mine also does the splitting, and it can split into a project terminal or a bare shell where I can just type. The other thing that I built in that was not there is an inbox. When I have all these agents moving fast through a lot of work, I can lose track of things that need my attention. It actually loads when there is something that needs my attention and gives me an inbox notification. (5:18)

Paul: I can then go in there and respond to the agent directly. I found that when using CMAX, everything would flow so quickly and I was keeping track of so many different agents that I would lose track of what one agent was busy with. I started building in solutions for stuff like that. With software before, you would just put up with all of these little inconveniences because it was really difficult to build software. Now we are in a stage where I think it is a lot more achievable for even a non-coder to build a system that suits their needs. (5:53)

Paul: I am completely a non-coder. Everything that I build is coded just based on my needs. (6:33)

Alexey: That is very interesting. I think everything that you showed right now is actually valuable even without video. You can probably stop sharing your screen. Most of the things you talked about make sense without video too. (6:38)

Alexey: If you are listening to this right now and you want to check what Paul was showing, I recommend going and checking YouTube at the beginning where he was showing these things. It is interesting how many people are converging to building similar stuff. I am building something similar for my workflow, and a friend of mine in Berlin is building something similar. Because our workflows are a tiny bit different, what I built is not necessarily something you would want to use. The main building blocks are the same. (6:57)

Alexey: We have a server where these things are running, and we connect to the server using SSH. Then we use tmux so the sessions are durable. There is an interface on top of this tmux that is specific to our needs and our workflows. I do not have so many Claude accounts. I only have one Claude and one Codex. (7:49)

Alexey: I recently started experimenting with Groq. I do not know if you use it. (8:11)

Paul: I have not experimented with it yet, but I have heard it is pretty good. (8:17)

Paul's Background in Film and Digital Marketing

Alexey: It is good. When I run out of usage limits for Claude and Codex, which happened last week, I have a backup plan. Tell us more about yourself. You said you are a non-coder and you completely coded it. What is your background? What did you do before doing all this stuff? (8:19)

Paul: I started off in film actually. I went to film school and was a video editor and director. I wrote movies and eventually ended up doing some adverts and TV shows. The money in South Africa in that industry was not enough. I started hustling with my housemate who was in digital marketing. (8:46)

Paul: I started doing a lot of affiliate marketing, Meta ads, and Google ads. I have been doing that for the last 10 years. It is interesting how much digital marketing and building with AI have in common. It is a lot of finding new angles, fresh solutions, optimizing, and fixing things as you go. As soon as AI started to become super prevalent, I decided to go all in. (9:14)

Paul: I started my agency. I am going to South African businesses and building them AI operating systems. I am doing that while building at the same time. I think that is extremely important in this game to keep up to date, to always be building. That is how you keep sharp and on trend. (9:50)

Alexey: One Claude Code subscription max is 200 dollars, and you have six of them. Codex is the same. In Europe you also need to add VAT on top of that, but roughly it is also 200 dollars. My rough calculation is just with these tools it is 1,600 dollars per month. We all know that these tokens are subsidized. (10:13)

Alexey: What you actually get from a 200 dollar subscription is way more expensive than this 200. Still, if you do the math, 1,600 is not something that is easy to just take out of pocket and pay every month. The return on investment you are getting must be totally worth it. How do you get back this money that you spent? What are the commercials behind this? (10:56)

Paul: The first point I would make is that 1,600 dollars is what you would pay for a mid-level coder or an engineer. It is not an extremely big amount to pay for a single employee. If I frame it like that, I am getting so much out of these agents. I have them running sales 24 hours a day. They are researching prospects on LinkedIn, tailoring messages to their specific pain points, and running cold email for me in the background 24/7. (11:22)

Paul: They are working to build my clients' work. With my next client that I am onboarding, I am starting to get them to subsidize the costs. I have been covering all of my own token costs up until now, but I feel like it is justifiable to expect the clients to pay for that as well. Also, considering the size of the programs that I install, I am not hunting for lots of small clients. I take on one or two big companies and charge accordingly. (11:59)

Paul: My ROI comes in with a single closed client. The way I work with clients involves long-term contracts. They start off with a three-month program that transitions into a maintenance phase. During the maintenance phase, I do not have to dedicate as much time, but I am still tweaking their systems. I am also charging on top of that to install new agents. (12:28)

Paul: After the three months that includes their entire operating system and a couple of agents installed, it transitions into a maintenance program with additional charges for new agents. Just three or four clients are essentially enough for me as a solopreneur to make a decent profit. The goal for me is to scale into a fully-fledged agency and have a physical presence in Cape Town. I want to get a few systems architects trained up to work alongside me. That is the goal over the next few months. (12:58)

Alexey: Your business is helping clients to do AI automation or AI transformation. (13:36)

Paul: It is becoming AI native. The more I do it, the more I realize that the real value is not in building them automations or agents. It is in giving them insight into their businesses. It is creating a source of truth that sits above their business and provides valuable insights. The other important thing is it gets them to ask the right questions. (13:49)

Paul: Everybody thinks about asking questions of AI, but that is actually quite difficult to do. A lot of people who are not AI native struggle to imagine what questions they can ask. I build this oracle to advise them on what they should be asking about their business. It looks at their business from a unique perspective, identifies what is most important for the CEO to pay attention to, and suggests questions to ask. That is where I see the real value, more so than automating mundane tasks. (14:19)

Alexey: Do you focus on a specific vertical or who are the clients you work with? (15:06)

Paul: It ranges. I like the startup feeling and energy. I like chaos because I feel like AI cuts through it very effectively. I am pretty industry agnostic overall. I have one client who does offline attribution for ads and they have a ton of different tracking systems. (15:11)

Paul: I am also working with a luxury beverage brand that operates around Europe and America. It is industry agnostic, and the problems are kind of similar. I find the AI does not need to care about what the business does. It just needs to be placed and installed correctly and connected to the right sources to be valuable. (15:37)

Sales Pipeline and Client Onboarding

Alexey: You have your agent doing cold outreach to find clients. Let's say somebody booked a meeting with you. You have this meeting and they want to proceed. What happens next? (16:09)

Paul: The sales pipeline is quite long, which is to be expected with high ticket sales. I do not try to sell anything on a call. I find myself wanting more human contact and spending more time in person. It has fed into the way I built this agency. I try to get from the call into a room with a decision maker and spend time with the team. (16:32)

Alexey: By room, you mean an actual real-life meeting. You focus on companies that have a physical presence in Cape Town or Johannesburg. (17:07)

Paul: Yes. The most important thing I realized is that in-person work is a lot more productive and effective. It also establishes trust and serves a lot of purposes. My goal after the first call is to build out a customized prototype for them before the call. (17:26)

Alexey: That explains why you need so many agents. If you find a company and schedule a call, you already have an agent doing research about the company to get public data and build a prototype. (17:52)

Paul: I try to get a few questions answered on my signup page. The goal is to find out the one question they would ask their company today, which I call the golden question. If it is something like why are their costs rising, I have a skill that my Claude agents use called a deep research goal. This fans out five or six sub-agents on different models to do a quorum of research on the prospect. It finds every piece of public information it can find and frames their pain point against what else we know about them. (18:25)

Paul: It comes up with an interview that I do with the agents where we discuss what the prototype will be. Once I am happy with the demo, I use Claude Design to build out the prototypes. I have a baseline reference of how the prototypes should look and what they should feature. Essentially, it is a guided tour of the AI operating system that takes them through each phase of installation. They are already living inside the product. (19:11)

Paul: I always give the product a personalized name that resonates with the company. The moment I know when something is working is when people start calling it by name. That second meeting after the initial call is generally in person, where I sit with the team. (19:57)

Alexey: On your first call over Zoom, you show the prototype and give them a link to poke around. When you meet in person, they have already been playing with the tools and can give you feedback on what needs to be changed. (20:29)

Paul: Exactly. I also use the transcript of that first call and feed it back to the agent. The agent does further research with more context on the business owner and updates the demo. The goal is to bring it as close to the vision and solving the problem as possible before I set foot in the office. By the time I get there, the second showing demonstrates how it has evolved from the rough prototype to something aligned with their vision. (21:05)

Paul: This carries through the trust and shows follow-through. It is a lot of time that goes into doing this, but once it sells, it is a long-term relationship that pays out for a long time. (21:35)

Token Efficiency and Open Source Models

Alexey: You have a funnel, and not every potential call results in a second in-person meeting. It doesn't mean that these tokens spent on building a prototype are wasted because you learn from every single interview. (21:56)

Paul: I never consider any tokens that I spend to be wasted. I waste a lot of tokens because token efficiency is not my strength. I like using the best models and definitely need to discipline myself, especially in using open source models. The next year is going to be very big for open source models, and people will realize you can get 80 to 90% of the way with them. Hugging Face has been valued at 14 billion dollars, and they are essentially a marketplace for open source models. (22:20)

Paul: I do not think tokens are wasted because the more time I spend working with agents, the more fluent I become in their mode of thinking. It all carries over as an investment in my future. (23:10)

Alexey: What is your go-to model? (23:36)

Paul: I like to use Fable. For client work, I literally do everything with Fable end-to-end. The quality of the output is so important. I find Fable very calming and it gives me clarity and insight in a way that doesn't induce panic like Opus 5 can when it goes off on rambling tangents. I use Codex a lot in chat mode on my phone, especially the voice mode while in the car. (23:36)

Paul: 5.6 Soul is a great model that I use for execution and computer use. If I could, I would use Fable for everything. It is just far superior for me. (24:23)

Alexey: My approach is using Fable for planning or auditing, and Opus or Sonnet for execution. For coding it works reasonably well, but for client work I would also want to ensure the quality is the best possible. (24:36)

Paul: I will often have Fable orchestrating a ton of sub-agents on dynamic graph workflows. If I am honest, I think Fable does things better if it just works alone on a single thread and barges through the work. There are many buzzwords going around like loops and harnesses, but I feel like your clarity of vision is more important. It is much easier to clarify your own vision with a model like Fable because it gives you such good feedback and insight. (25:01)

Alexey: I have been in the AI world since 2012. Even for me, keeping up with buzzwords is very challenging. You open Twitter and see things popping up every day. As someone who is not a developer, how do you manage to keep up with all this stuff and decide what to try or ignore? (25:58)

Paul: I think you have to go down the wrong road a number of times. With Twitter initially, I would go after every thread like a Labrador chasing a tennis ball. I would go down rabbit holes like building a second brain or rebooting my architecture to run on loops. (26:38)

Alexey: Why did you want to chase all these things? Did you see value in these things and want to learn how to be more efficient, or what was the motivation? (27:01)

Paul: It is Twitter. The way posts are worded makes everything out to be the next big thing. Sometimes there is real value in those threads, like understanding context engineering. I went down a lot of rabbit holes that weren't massive magic bullets, but they were valuable enough that I learned stuff along the way. I have developed a strong radar for these posts now and tend not to go down those rabbit holes. (27:20)

Paul: I scroll past posts like the leaked Anthropic memory system. I still spend a lot of time on X because it is the easiest way to see what is being built and what fellow people are doing. That is how we found each other. What you mentioned earlier about everybody building agent operating systems is exactly what I have noticed. It is kind of like a hive mind. (28:12)

Paul: I used to find this in digital marketing too. I would have an original thought and then see it all over Facebook. There is definitely a collective consciousness because I am seeing everyone building agent operating systems now. (28:50)

Alexey: There is an effect when you start a podcast, you notice everyone else is doing a podcast too. Maybe they were doing it before, but you just didn't pay attention. Now it looks like everyone is building an agent operating system, but maybe we only notice because it is a problem we share. (29:06)

Paul: The algorithm obviously sees you paying more attention to this type of stuff, so it shifts you. That could absolutely be the case. It is very interesting regardless. (29:48)

Curiosity and the Learning Process

Alexey: How did you develop this radar? What is your approach to learning? With context engineering, dynamic workflows, and graph workflows being buzzwords, how do you decide if you need to learn them? You cannot call yourself non-technical anymore because you are coding and running many accounts and agents. There was a journey, and I am interested in how you approach learning now compared to a year ago. (30:00)

Paul: The cornerstone of it is relentless curiosity, which is only possible if you are genuinely interested in something. I do not feel like I have ever been as interested in anything as I am in AI. It is almost a magnetic pull of curiosity and it is dangerously addictive. It can make you feel like you are being extremely productive. (31:19)

Alexey: They call it AI psychosis, where you go down a rabbit hole thinking you are achieving something but not moving the needle. (31:57)

Paul: My early stages of getting into AI were full of that. I was trying everything I could get my hands on and building things that were kind of useless. (32:02)

Alexey: It is a productive psychosis because it is a journey. You have to try things before you know they don't work. If you build something, it might work or it might not. (32:28)

Paul: You have to believe deeply in what you are doing at any given moment. You have to believe it is the biggest thing and that it is going to work. Nine out of ten times it is probably not going to work out, but you have to be willfully delusional and allow yourself to go down the rabbit holes. After doing it enough times, you learn from the iteration of failing and trying again, just like agents do. You apply that process of learning until you reach something good. (32:45)

Paul: That is how I got to the point where I feel like a lot of what I do with AI is productive and brings real value. It is easy to fail without intention and clarity of vision, as seen with billions invested in enterprise AI programs that failed. (33:40)

Alexey: What is your approach to learning now? If you see something genuinely interesting on Twitter, what do you do next? (34:18)

Paul: The first thing I will do is ask Fable to apply the methodologies shared and do a direct comparison to our current systems. I have it evaluate it on a bunch of different metrics and come up with a rubric to score the new system. (34:48)

Alexey: You ask yourself if you can use it for your current system, not just if you can learn it. For learning, it has to be practical as the first filter. If it can potentially be useful, you ask Fable if this approach will be useful for your current workflow. (35:15)

Paul: It needs to spark my imagination. I need to see the idea and think it could solve a problem I am currently having. When you try and adopt these ideas wholesale, you end up sinking so much time to make so little progress. I have Fable bring to light if there is utility in the idea when combined with our existing systems in a symbiotic way. (35:52)

Paul: I have become very familiar with the term blast radius. I ask if the blast radius of implementing an idea is going to screw up my whole estate and have agents rebuilding our entire infrastructure. If so, I ask Fable to err on the side of caution. I looked into using Devon, a coding harness with an engineering bent, and realized it would be inharmonious to integrate into my current workflow. Right now, what is most important and how I am learning the most is from actual real businesses' needs. (36:37)

Paul: The problems are specific, unique, and real. I am spending a lot less time learning from Twitter and a lot more time learning from building work for clients. (37:33)

Red Teaming and Code Audits

Alexey: I have a problem sometimes when I see a Codex usage reset coming tomorrow. If I still have 60% left, I come up with a crazy idea to burn the tokens. Do you have this problem with your six Claude and two Codex accounts? Do you worry that some sessions are not fully utilized? (37:52)

Paul: The first thing I will do is send out red teams. I will get Codex to red team my codebase for reliability. I have a prompt that does a comprehensive simplification audit of a codebase and comes out with a list of P0 and P1 fixes that should be implemented. I will have a Codex agent blast through those audits and findings. I usually have around 50 findings queued up that I send Codex to smash through if I know a reset is coming. (38:38)

Paul: That is why I built Headroom. The agents make decisions on how to utilize my usage effectively and which account to choose. (39:45)

Alexey: If you have six accounts and some are closer to zero than others, does it do any smart dispatching to use a specific account for a task? (40:01)

Paul: Absolutely. Fable makes it interesting because you can only use 50% of your weekly limit on Fable. I have created rule sets so the agents do not let the seven-day limit run out while there is still Fable left. They utilize Fable to ensure we get the full 50% usage. It will also try to watch the five-hour limits. (40:20)

Paul: It won't assign the same accounts to multiple agents churning through tokens because that hits the five-hour limits. When an account is at 7% of its limit, it rotates to a more suitable account. The trick is rotating the login in place so you do not lose context and kill sub-agents. (40:50)

Alexey: Can you keep the context? (41:21)

Paul: You can keep the context. I use automated baton handoffs. When an agent is at a 30% context limit, it builds out a comprehensive context window and passes it on to the next agent. (41:21)

Alexey: You ask it to create a handoff document because you are about to stop the session and another agent is going to take over. (41:51)

Paul: This happens automatically. I think it is a little bit of paranoia, but after context has churned twice, degradation starts to set in and you lose context from earlier parts of the session. It works better for me to rotate at a 30% context window automatically. (42:02)

Alexey: You called yourself a non-coder, but you have an engineering mindset. You observe when something is not working and ask agents to come up with a fix. As someone with a non-technical background, how do you choose technologies? Do you rely on agents or how do you go about this? (42:25)

Paul: I try and focus on what I am good at, which is not the technical deep elements of choosing the right code language. I feel like we are moving towards a space where none of that is going to be relevant. I rely on my agents completely and rely on outcomes. I know what good looks like and how I want it to behave. I am a blind systems architect in that I know how I want the system to work from a high level, but I have no idea about the intricacies. (43:00)

Paul: I haven't needed to know that. AI unlocked the ability to build things that used to require layers of technical ability. I can marry my creative perspective to technical problems. (43:55)

Building Software Without Knowing the Tech Stack

Alexey: For Headroom, how did you choose the technologies like Python? Did you ask the agent to implement it and go with its suggestion, or did you ask for a list of technologies and their pros and cons? (44:26)

Paul: It all starts with a problem and I use Whisper flow. I am constantly talking to my agents. Headroom came out of me constantly having to copy the URL, log into the right Claude account, and paste the authentication code back into the CLI. It felt inefficient. It always starts with a little annoyance or inefficiency. (44:44)

Paul: I express that feeling to the agents and they help me brainstorm and execute the solution. I judge it based on the outcome. (45:34)

Alexey: At the end, it doesn't matter if it's Python or TypeScript. You just state the problem and ask to solve it using the best possible way within your constraints. If it works the way you want, you do not care what technology it uses. (45:55)

Paul: Not at all. I didn't even know that Demox was built on TypeScript until yesterday. It is not something I consider to be a needle-moving element. Even if AI isn't perfect and some visual elements are annoying to fix, I do not think this stuff is important. It is about having a clear understanding of what you want and expressing it clearly so agents can understand. (46:18)

Alexey: When you see that an account's limits are going to reset soon, you ask for a comprehensive simplification audit. How do you know it is needed? Do you know from experience that agents tend to overcomplicate things? (47:14)

Paul: Even with my limited knowledge of coding, I know that agents are not very efficient and can build up massive piles of technical debt. The thing I am always trying to protect is context because when agents lack context, they start breaking everything. Without fail, if you run an audit with Codex, it will have findings. It has never said the code is perfect. The key is to take that audit, set it as a measuring stick, and stick to it over days or weeks. (47:39)

Paul: I used to have agents implement the audit but would lose track of what was done. Now, I have Fable report daily on our progress toward completing the audit findings. That works wonders in keeping a measurable North Star for the agents to work toward. I do not need to know what each finding does; I just know if there is improvement toward that North Star score. (48:30)

Alexey: Having a background in marketing really helps because you need to measure things. In marketing, you deal with real money and need to know the return on investment. This data-driven mindset is very helpful. (49:34)

Paul: Especially with performance-based marketing like affiliate marketing, your ROI is your living. After years of trying to squeeze a profit out of Meta ads, you develop that data-driven methodology. (50:16)

Building Software Without Knowing the Tech Stack

Alexey: What did you do before marketing? (50:50)

Paul: I was a film director on film sets. That feeds in because it is about having a vision, writing a story, and turning it into reality by coordinating people. (50:57)

Alexey: That is like project management. (51:24)

Paul: It involves an obsession for detail and making sure your vision is adhered to without compromising. Good filmmakers are extremely stubborn about making their vision a reality. The same applies to building with AI. (51:29)

Alexey: I see the parallels. You have business acumen to measure and keep things moving. People with managerial experience are quite good at managing agents because they know they need to be explicit with tasks. You can come from all sorts of backgrounds and have useful experience for making an agentic team work. (51:55)

Paul: I wonder how long that is going to be the case. Inference is getting better and better at inferring what you mean even if you are vague. A model like Fable never ceases to blow me away with how close it gets to your idea even without explicit prompting. It still remains vitally important right now to be clear in instructions. I wonder how long it will be important before things like Neuralink reduce bandwidth and instantly materialize our thoughts. (53:21)

Alexey: Do you also use AI for other things with friends or family? (54:37)

Paul: I am planning my wedding. I use AI a lot with my six-year-old son. I let him describe what he wants to see, like a monster with horns, and bring his imagination to life using ChatGPT. I also built a custom-made physical board game stuck to the wall with his favorite video games. He gets to roll a coin every day if he behaves well, and it keeps him excited. (54:48)

Using AI for 3D Printing and Personal Projects

Alexey: Do you have a 3D printer? (56:25)

Paul: No, I don't, but I would love to. (56:25)

Alexey: I got a printer three months ago. Three months ago, ChatGPT couldn't design a toy car to print. Now it can. There is a tool called AutoSCAD that can write code to generate an object and render it. You would love it. (56:32)

Paul: I need to do that. There are obscure video game enemies my son loves that they do not make toys for. A 3D printer would be cool to make those. (57:27)

Alexey: In Germany, you can get a Bamboo A1 Mini for 130 euros. If something is broken, I can take a picture and ask AI how to fix it. (57:38)

Paul: That is why it is more important than ever to maintain human connections. We don't really need help from others for technical reasons, but we need it for emotional reasons and collaboration. (58:19)

Alexey: A friend came over, saw the printer, and now he has one too. We discuss what to print. (58:41)

Paul: You are doing good marketing. I will have a printer as well. How is it going with affiliate commissions and adverts? Is the podcast a hobby? (58:59)

Alexey: I only spend money on the podcast, so I am not earning anything from it. The way DataTalks.Club works is that when people sign up for the podcast, courses, or events, they get into the newsletter. Every week there is an ad in the newsletter. I try to make sure sponsors are a good fit for the community, like promoting products for data engineers, not random items like chairs. (59:29)

Paul: It doesn't work for them if you place misaligned ads either. (1:01:00)

Alexey: I am satisfied with my Herman Miller chair anyway. Do you listen to podcasts yourself? (1:01:12)

Paul: Sometimes, but not actively. (1:01:31)

Alexey: When I was starting the podcast, I listened actively to side hustle podcasts. Now I listen to audiobooks on Audible. (1:01:36)

Paul: I advise you to listen to Anna Karenina read by Maggie Gyllenhaal on Audible. It is my favorite audiobook. (1:02:14)

Alexey: Are there any books related to what we talked about today that you can recommend? (1:02:32)

Paul: I don't read a lot of self-help or technical books. I read for pleasure and emotional enrichment. I do like biographies like Steve Jobs. I find inspiration in what humans can achieve. Currently, I am reading The Power Broker, which is about the man who built New York City. He was a terrible man but an incredible achiever. (1:02:39)

Alexey: It is interesting that great achievers are sometimes not the people you want to be around. It is the same with some musicians; I admire their art but the people are terrible. (1:03:42)

Paul: Separating the art from the artist is quite nuanced. Have you taken any courses about AI and managing agents or is it all learned by doing? (1:04:08)

The Importance of AI Evals

Alexey: I looked into evals with Hamel. Evals are one of the most important aspects of AI that we haven't spoken about. I learned a lot about LLM as a judge to ensure agents produce consistently good output. His courses are very productive. He is writing a book available on O'Reilly Learning. (1:04:34)

Paul: I definitely think I'll give that a read. Evals relate to a human's perception of output, which models won't just solve. They will never perfectly infer what a person wants. (1:05:28)

Alexey: Everyone can code something, but properly evaluating it is something we need to know how to do better as a community. Thanks Paul for joining and sharing your experience. (1:06:04)

Paul: Thank you. It was a great pleasure talking to you. (1:06:27)