build in public #1 - project showcase

This is my very first Build in Public blog, but I wanted to go away from just very well-researched blog articles because I'm not a pundit, I'm a builder.

So I want to show you what I'm building because if I did this, I would have a lot more content, and I'm pretty sure that you guys are more interested in this one.

So today I want to talk about 4 things— things, Alfred Dovetail Joe and Jake.

Alfred is the project that you guys know about.

Dovetail is a new project that I teased in my latest blog article, which helps me be not just more productive but also be a better engineer without having to be a better engineer.

And then Joe and Jig are client projects, which I'm going to talk about in just a few minutes.

And then there are a couple other fun stuff that I'm going to show you.

So, Alfred— I started working on Alfred, last August, right, when I said I'm building my own butler.

Because basically what I wanted— And everybody was promising that with AI, but it's not doing that.

And it's pretty annoying because of hallucinations.

And I And then even a couple months later, MCP was introduced in November, and I'm like, yeah, that's what we need.

But even that is very brittle.

So anyway, I started building n8n workflows, because that's actually easier than coding.

At least that's what I thought.

And then basically I figured, hey, I want Alfred to just run these n8n workflows for me and build these n8n workflows for me.

And then really quickly I realized that a big problem of this is connection, like having MCP connection and then not paying a shit ton of money to Make.com or Zapier or n8n.

So I need self-hosting, and then I went into this whole self-hosting idea.

So I started building on Alfred OS, which was supposed to, host a bunch of open source applications for you and just run a bunch of apps, but the open source alternatives for that.

So like instead of Make.com, let's use n8n because you can self-host it.

Instead of Zoom, Jitsi because it's the same thing but open source.

And then I would have skills for Alfred, n8n workflows that can really do stuff well.

And then, you know, if I want to use MCP servers, I can just add them to skills.

But the point is that an Alfred skill would be deterministic, right?

That's the big problem that I've had because you go into Claude and you create a bunch of connectors and then it starts doing stuff with the MCP servers, but then it starts hallucinating and I need someone to hold the agent's hand to not drift off because the moment it starts working with lots of data points, it starts to drift off.

And what happens if I'm like, hey, get me data from this, from this, from this, from this, and then prepare a report for me and then— then— it's just so much bloat and data that it, it drifts off.

So that was one big problem.

And the second big problem was again, I'm shit at DevOps, so I needed to figure this out somehow.

And ultimately I ended up creating a Railway template, which know, you click once and it deploys a bunch of apps, like n8n and NoCodeDB and cal.com.

Some of them work, some of them don't.

And then it also deploys a custom version of LibreChat, which is just a ChatGPT clone that would allow you to use your own API keys to have a chat with Alfred.

And then with all— inside Alfred, Alfred would be connected to all the apps that you had.

And I'm like, yeah, that's pretty cool, but I still want the N8N workflows to be running automatically.

And that— for that, I would want it to be, you know, hosted locally because I want the hosting part to be done.

So I'm not paying for the cloud version.

and then the N8N licensing issue was a big problem because that I cannot do unless I pay pay up $50 grand a year and I don't want to.

So I was kind of stuck, right?

I wanted Alfred to just know things and, and, and do things and save money.

And then the ultimate idea was that I would have Alfred and then boom, installs the, the whole Alfred OS and the agent and the skills and everything on a server, and then Alfred can do stuff for you.

Now the problem is, even if I solve that I still cannot work with NA10 because I don't have the embed license.

So instead of doing that, I needed to figure out some other ways, and there are a couple other ways.

Like for example, what's really promising is Manus.

Now has a thing.

It has an API, right?

I don't even know where the API key that— or maybe here.

So Manus has an API, which means that I can just give tasks to Manus.

But the problem still remains.

It's like, okay, I don't have to do the N810 thing.

I can still probably figure out how to build the cloud bit, but I never done that before.

But even then, this is not really going to be entirely free because you still need to pay for credits.

So I decided to kind of streamline the whole to— what I'm showing you is something that I built in the last 3 days, and this is how powerful my new workflow has become, is that I was able to solve a problem that I don't have the skills for in, in 3 days.

So the idea of Alfred is basically it's an execution layer for right?

You get an MCP server, you connect it to Claude or ChatGPT or whatever, and then it just knows things, does things, and saves money for you, and that's it.

And how it works, it's, is not technical.

It is technical, but your experience of it is not technical.

So there is a big, big problem with AI execution, which is These things are very smart, but they're not logical.

They cannot employ actual reasoning, which means that reasoning unlocks deterministic workflows.

I tell you to follow step 1, 2, 3, 4 in this order, and the AI may or may not do that.

There is no validation, there's no enforcement, there's no deterministic stuff.

For that, you need to write code, and that's kind of the plumbing that's missing.

So basically, we would need separation of concerns.

We want the agentic work, which is flexible and scalable, but also can hallucinate and, and be unreliable.

Reliable, but it's really good with unstructured information.

And that unstructured information is the idea I have in my head.

and— but once it's clear enough, I want the AI to kind of lock it down.

It's like, hey, here's the deterministic way of getting things done, and here's how I'm going to do it again and again and again.

Claude skills are a, pretty good move in that direction, right?

There are agent skills inside Claude But these are just mega prompts and short scripts, and it's not entirely what I would want.

So it's like, okay, we're getting there, but the flow I'm expecting is— and the original flow I was expecting is I talk to Alfred via chat, and then once I figure out what I want, Alfred builds an N8N workflow for me, and then I can set when it should run, or I can just say, hey Alfred, run this for me.

And that would turn Alfred into an operator, like a chief of staff, but AI.

And it doesn't work because all the N8N workflows Claude or any other AI tools can build are not very good right now, and it's just— it's just brittle.

So we need something better.

And the MCP was an idea that, you know, MCP servers, and I just the tasks to Alfred— to Claude, and then it just calls the MCP tools.

But it's it's then— it's unreliable and hallucinates.

So I either have spaghetti inside Na10 that I need to plumb, or I use an agent that tries to kind of cosplay as Dexter from Dexter's Laboratory, but really it's DeeDee.

And that, that's the big problem.

So in order to solve that, I came up with two things called Talk Mode and Work Mode.

And the version of AllFree that I'm building right now, basically what you get is that the moment you log in, What is you get deployed, you get provisioned a new server.

So let me show you.

This is the current version.

It's, it's very early but I'm using the OpenSaaS template.

It's running on a WASP framework, and I definitely recommend you take a look at it if you want to build apps because it's complete stuff— Stripe integration, authentication, everything.

So When you're in Alfred, it's, you know, the namings and everything are not, done yet.

It's all running locally, but the idea was I log in and then when I log I would just click on Launch My Alfred OS and then it starts getting created.

And then when it gets created, it's pending, which means there is a server, remotely that's currently setting things up for me.

I'm currently using Contabo because I'm going through the verification process with Hetzner, which I don't know, I've built— I've opened bank accounts with less scrutiny.

But if you look at it now, it's provisioning, and now I got a specific URL, dynamicpheasant.alfredoess.site.

This is set, the DNS configuration is set, but you also get the IP address.

Now currently nothing's installed on it..

But now there's an automatically generated virtual machine that I can— that sets itself up and then with a setup script.

And then inside that setup script, I can add whatever app I want to add.

So that's the next step.

So I solved this and, we're getting pretty close to the Alfred Cloud because the big change is that I let go of the idea of installing N810 on this.

okay, so once you have that installed, you will have basically two apps that comes with the install: LibreChat and NoCodeDB.

And that's, very intentional because you're not— probably you're never going to have to open that.

What you're gonna have as a quick start, you're going to get a simple URL and an API key, and all you need to do is go to Claude or ChatGPT and add Alfred as a connector.

And once you add Alfred as a connector, then you can open Claude and say, hey Alfred, do this and do that, and it will actually use Alfred instead of Claude.

Like Claude turns into Alfred for that session.

this is the chat part.

If you want to go to LibreChat because you don't want to use Claude, you can still open the LibreChat.

That's why it's there.

You can open LibreChat and, and use Alfred there..

It will have the MCP connections to, to NoCodeDB.

It will have all the MCP connections you want to, and then the Alfred MCP will do the same thing that LibreChat can do.

So there is the same thing.

But the, the use case here is not that.

And that was my biggest pet peeve, is that I was getting distracted with the Alfred OS.

This is just an infrastructure thing.

And now, now that I figured out how to run this, I will just create Alfred Cloud where you pay, I don't know, probably $40 or something per month, and then you get a server, full access to it if you want to.

You get a and then, it runs Alfred, it runs all the apps, it runs LibreChat, and then you have your own little thing and all the data is yours.

but the interesting thing is happening inside work mode because the idea that I want— I have is that I want to teach Alfred a skill once.

And then I want Alfred to just remember how to run it forever.

So I would just describe something like, hey, process my emails and organize them into labels by topic of importance.

And then I want Alfred to automatically look at my connections and see what, what's what, like get the context on my, little world, my reality, and then come up with an idea of how this should actually work.

And then it comes up with a solution.

It's like, hey, I think what we should do is connect to Gmail and then fetch unread emails from the last 24 hours, etc., etc.

And then also give me a couple ideas like, hey, what if we do a sentiment analysis from another MCP server as step 4?

Or what if I do this and that?

And you say, okay, you know what, I want you to do option C.

And then I just say learn it.

And then when I say learn it, then Alfred— it doesn't save the skill into memory.

It actually creates deterministic code that will trigger Alfred running every time, the exact same time, the exact same way, the exact same tools are being used.

It's deterministic and reliable and does the exact same thing all the time, much like an N8N workflow, but you just built it in 4 steps because you let it.

Alfred do the heavy lifting for you.

So talk mode and work mode is really just separation of concerns, right?

Talk mode is about authoring.

It's like ad hoc conversations, exploration.

Hey Alfred, do this, do that.

And then whenever something happens, it's like, hey, what we just did, just give me a, like a few-step walkthrough of what you did and what tools you used.

And then when Alfred gives you something like, this is a really good workflow, I want to learn it.

And I want you to run it every Monday at 7 AM.

And then Alfred actually transforms that into a skill, and that replaces an n8n workflow.

And, and that's it.

Inside WorkMode, this— you will have a trigger, you will have the actual skill which have the actual steps, and then Alfred always runs it, completely deterministically all the time.

And then the idea here is that You know, Claude skills are supposed to kind of do that, but the authoring bit is missing and the orchestration bit is missing.

The execution layer is missing.

So let me give you a couple examples.

Let's say I just type in, hey, every Monday I want you to pull revenue from Stripe, support tickets, project updates, Slack mentions, and then send me a summary on Slack.

And then Alfred understands what I want and then it creates a workflow suggestion And then it's not like a 45-node spaghetti.

It's really just 6 steps, right?

Because it's like agentic in execution, but deterministic in orchestration.

And then once I say, yeah, that's it, learn it, then it saves it for itself and it will done those— do those steps exactly the same thing.

Or another thing, it's like, hey Alfred, I want you to analyze support— my support tickets, find buying motives, build our ICP, research leads in Apollo, and then save them into my database.

Base.

Like, that's a pretty big work.

So I'm like, okay, let's see, let's— we trigger this manually and pull support tickets via Zendesk.

Then I'm gonna analyze— it says off via AlfredOS, which means that Alfred is thinking, instead of using external tools.

So analyze buying motives, build ICP.

Then based on that, I'm going to use the Apollo MCP to research matching leads and then save them to the database.

Base.

And then I can also do stuff like self-maintenance, right?

I can just say, Alfred, I want you to— every Monday, I want you to analyze our conversations from the last week and suggest me skills to add or remove or improve.

And because can examine itself, it will pull conversation from the history from last week using its own MCP, then analyze skill usage patterns, identify gaps, generate improvement suggestions, and then send you a report via Slack.

And then Alfred might suggest to relearn some skills if there are some, errors or something.

So you don't need to deal with any of that.

another example, which is, something that I started working on, is I have a Home Assistant, unit here at home, and I started, connecting everything.

And then there is the Home Assistant, voice preview addition.

Which is, which is basically like Alexa but, for Home Assistant.

And then you can run anything on it.

So I have a Home Assistant voice preview.

It's downstairs in the kitchen.

It's connected to, chat— it's connected to OpenAI.

I think it's using GPT-5.

And it's also— also has the, the iconic Alfred voice from ElevenLabs.

And, and that's it.

So then I have cameras, I can— I have smart, switches and stuff.

So what I can do is I can say, hey, if someone's at the door and I don't reply on Slack in 60 seconds, call my phone.

So then Alfred is like, okay, first I need to have a workflow created.

Trigger would be a doorbell event.

I need to figure out what that is.

I just connect to Home Assistant through an MCP connection and find that event.

And then I will just— okay, that's the webhook that I need to set.

So you don't need to deal with any of that.

And then it's like, okay, step 1, detect the doorbell rings and Slack alert, wait 60 seconds, no response.

If it reply— replies, then, you know, I can see that on Slack, so I don't do anything.

If no reply, then I'm going to initiate a phone call, which can be either via Twilio or it even can be using VAPI, which, you know, just have a voice agent.

So Alfred can actually call me and say, David, someone's at the door.

Like, go check it out.

You're not looking at right now.

So, the idea here is that this is the kind of stuff that I want to use, and it's pretty annoying to me that I can use Clothen skills and everything, but it's not doing the stuff that I would want to do, because it's hallucinating, or I can build N8N workflows, which are again not doing what I want because they're so complicated and spaghetti and they're brittle and fragile and, and unreliable.

So the idea here is that Alfred will come together as everything, right?

You get— you just click on deploy once like you did here.

If I, if I, refresh, you can see it's running, it got an IP address, it got a host, and that's it, and everything's there.

So log in, sign up for Alfred, then you get an MCP server and API key so you can start immediately using it.

Then, Alfred OS gets deployed into that server for you.

So Alfred has instant connection to open source tools, and then you will have apps that, you— like open source apps.

I'm probably going to build or add more apps the App Store, and— or you can also add your own MCP connections.

Like let's say you love Zoom, you don't want to use Jitsi, so instead of installing Jitsi on Alfred OS, and you're going to just create an MCP connection for, for, for Zoom to Alfred.

And from that moment onwards, Alfred understands what's about.

I'm probably going to have— for the Alfred Cloud, we're going to have a solo version, which is going to be the lowest tier, and going to be, you know, including the, whole thing, very basic LibraChat and NoCodeDB, and then whenever there is new apps coming up in the App Store, you immediately get access to them, but you can start using Alfred immediately.

I'm not entirely sure about the pricing.

It may be— I don't know, it, it may be, usage-based or, or like skill runs, runs, or it may be a simple monthly fee.

the AlfredOS bit is just, you know, it's, it's flat.

It's, it's, it's— you have full root access to the server, and on top of that you have Alfred as the agent.

the way the Alfred OS gets deployed, I'm still going to make that open source.

So if you don't want to use Alfred as the agent, just want the self-host stuff, you get to that.

then, I'm I'm I'm also thinking about, another, tier, I'm not entirely sure how this would work.

I may just have the Alfred solo and that's it, and then, you know, you can add as many MCP connections as you want.

But the whole point is, you know, collaboration and, and skills library, because the real value is going to be in skills.

And then for those who have existing businesses and they're like, hey, I have a bunch of that I need here, I have the Alfred Pro subscription, which would come, with a white glove onboarding, and I will, I will come on board and help you create the skills, help you set everything up for yourself, and then you just get a URL to log in, and you also get the Alfred MCP, setup as a one-pager.

And then, you know, we would monitor the skills and the skill development.

So, so you really get sort of a performance supervisor for your Alfred AI chief of staff.

don't know about pricing yet, I'm still thinking about it.

There's a lot of stuff to do.

I just want this to work first.

And finally, it sort of clicked everything together and it works and the skill gaps are closed.

So yeah, I'm going to launch this website soon and, and, and, probably give some more updates.

But also because I don't want to just, you know, show you and talk to you about theoretical stuff.

I have started using Linear for tracking my work, and inside Linear I have a bunch projects.

Some of them are, are, you know, client projects, some of them are my own projects.

And here is Alfred, Alfred, which to my project management tool, again Linear, and it has all the stuff that I'm working.

So full build in public mode Right?

Full build in public mode.

You can see all the stuff that I'm working on.

you're going to see how these are created.

I'm building everything with Cloud Code.

So this is public and I'm going to share the links to the different roadmaps, to the different products I have below.

And, and you will have the ability to, to keep track of things and ask questions and whatnot.

So again, I want to build fully in public.

yeah, so, so this is Alfred, and, I— probably the first question most people are gonna ask is when is this gonna be ready?

honestly, I don't know.

I keep building it, and now I feel like it's probably going be closer than I figured.

there are a couple people who paid, for the original Alfred, and I will give them the option to either have, for the Alfred Cloud, or, use, use it for sort a white glove onboarding session, and then, you know, keep them on.

So I don't know, we'll figure, we'll figure things out.

A couple months ago I suggested that if you paid for it, you can just ping me and I will help you set it up for yourself however you want.

That still stands.

Okay, so I'm going to keep posting about what I do.

The first video is like pretty long, but, I'm going to start releasing more updates to you on YouTube and here on, on the Lumberjack.

And it's just, you know, immediacy.

Hey, here's what I'm building, here's where I'm at.

So you will be able to see that.

Now, how and why can I do this?

So then we get to Dovetail.

Dovetail is a really interesting project because First, here's the evolution, right?

I started with IFTTT in 20— 2014.

That was the first time I built a no-code automation, and it was— I think it was archiving photos from my iPhone to Dropbox.

And back then, I was running a software company.

I was designing and launching products, and I was raising VC funds and doing stuff, and And I did a lot of technical stuff in my life, but I never really coded.

So this whole no-code idea pretty cool.

And then as, you know, life happened and the AI thing came and, and then, I— there was the Promaster era where I really got into Make.

So in make.com, I started using it in 2023 and I got really, really big on that.

But the problem was it got really expensive really quickly.

So in 2024, I moved over to N8N.

And the interesting thing about here is that these are progressively more and more complicated.

Somewhere in between these two, I was using Zapier, but that's like super expensive.

So with n810, it wasn't enough, so I had, had to add JetBrains, which was, not JetBrains, sorry, let me me check for— check it.

So I joined— I started So I started using JetAdmin for creating, a UI.

And then there are a couple solutions like that, like Bubble and Softr and Framer a couple other stuff.

So, I was looking around and then I started getting into, using Airtable a bit more and then I moved over to Supabase.

So, you know, my stack started expanding, getting more complicated as I was building more more complicated stuff.

And then, in 2025, I started using Lovable.

And basically, Lovable plus Supabase replaced everything else.

So I didn't need to use N8N, I could just create Supabase Edge Functions.

I didn't need to use JetAdmin because Lovable was building the UI.

I didn't need to use Airtable because Lovable had a native Supabase integration.

I felt powerful.

It was really good.

But then the problem is the same thing that we discussed with the Alfred problem, which is it's brittle.

Even lovable UI gets really, really, complex and, and brittle very quickly.

So it wasn't very reliable.

So I started focusing more and more on dev work.

I was learning a lot of stuff, and then ultimately I ended up using Claude Code.

Claude Code., a lot, right?

So with Cloud Code, I tried Warp, I tried Cursor.

I even used Cloud Code in the simple terminal or PowerShell, and, you know, it works perfectly.

It's fine.

So Cloud Code is pretty cool.

And, then I started going through like a productivity boom, right?

So then I went into Cloud Flow.

Which is built by RivenCoin, and and it basically launches a bunch of cloud code instances, and then you just, you know, have an agent swarm that builds stuff for And I don't know, man, it's, it got— it got overwhelming really quickly because the hallucinations problem was still there, right?

So Claude Code was really great, but the— it was still hallucinating and making stuff up.

Claude Flow is the same.

I love it, it's pretty cool, but there is a lot of it that's just smoke and There's a lot of, you know, I don't know, there's a lot of tricks in there, I think.

so after a while I realized that basically, I have the same stack every time I work., right?

All of— almost all of my projects are almost always built on the same stack.

I use Supabase for DB, I use Supabase for authentication, I use Supabase for serverless functions, and, and for, APIs as well.

It just gives you— like, you, you create a project in Supabase and then you're done.

I started using Linear for documentation and project management, because I was— I was— I wasn't doing anything correctly.

So I had to start forcing myself for— to start documenting stuff.

And then I started using Fly.io Fly.io for hosting.

It's pretty cool, it's pretty lightweight, pretty thin, and you just create an app on on Fly.io, deploy it, and runs it.

And Cloud Code can deal with it pretty easily.

So I'm like Supabase, Linear, Fly.io, And then I was still using Lovable for UI, but then immediately once I have the UI more or less nailed down, I will move it to GitHub and then pull the GitHub repo into Cloud Code and keep working from there.

But again, there were a couple problems, namely around code changes and commits, commits and auditability, etc.

So the big problem I had with this is that I just kept working and working, and then in the beginning I was looking at the stuff that Claude Code was changing, but then after a while I got complacent, and then, you know, it started replacing entire working features with placeholders for no particular reason.

So I needed to learn a bit more about, about, branches and pull requests and everything in GitHub.

But then, then all of a sudden I had this whole idea that, okay, so I have an idea, I go to Claude Code and I say, hey, do this and change that.

And then Claude Code, out of context, it just pulls stuff from its memory and then it starts building something and then it pushes it to GitHub, which then pushes stuff to fly.io and it gets deployed.

And then if deleted something from the database, like, I need to go back, but I don't actually realize it until like an hour later.

So in order to make this work, I needed to have a pretty strict flow, right?

I needed to— first of all, when I start working on a project, I don't want to deal with any of this shit because anything— everything needed to be connected.

So, but let's say I have this set up, everything is set up, so Then what I do is I send the prompt.

Let's say I start Claude code, code, and then Claude code, code or me.

Somebody to check the Git repo status, status, latest commits, latest, latest updates in linear, connections, and basically get, get the context or get context on what's what, right?

And then I say, okay, send the prompt on what to build.

But if I'm not doing it, right, if, if it's manual, then inside the prompt, in the prompt, I would need to do stuff like, check linear, check DB, do this, do that.

And even then, in order to like do everything properly, I would need to say check linear to see if my request is related to any issues, issues, then check the latest commits on GitHub to see if we worked, worked on this before, then figure out what I want, right?

And then if it figures out what I want, instead of just starting to build it, I would need to say create a new— or, or move to a new branch in Git.

And start working working on that.

Once done, create a pull request and update Linear.

So if it's manual, then I do all of this before I send the prompt, or I could just say Claude Code does it.

Claude Code does it, and then we could have skills, which is automatically invoked or not.

So I don't have control over that.

That's not really good.

I can use a Claude, Claude.md prompt, which again works or not.

So then we have the new Claude plugins, which was pretty cool.

You know, it's, it, it does— it kind of does what I want.

But I was like, okay, so Claude plugins are basically commands and hooks.

But what is the hook that we're running here, right?

how do we, how do we make it work?

so I was— I had the idea of launching sub-agents, but then again, it works or it doesn't, because then the agent is doing the orchestration.

So anyway, so I decided that none of the current solutions solved this, so I started working on Dovetail.

And what Dovetail does is, first off, I can just, I can just create— I say dovetail init.

Let me show you.

So basically the way you install Dovetail is you say it's on npm, so npm install g numberjankso/dovetail, and then you install it, and then it pulls the, pulls the package from npm, it, it pulls the, the, the code, and then You can check the version, and then this is the current version, and you can take a look at all the different— all the different commands Dovetail currently has.

If it's the first time you're running, you can go to Dovetail Onboard, or if it's not the first time, you can go to Dovetail Config.

And in the config, you can see that there are a bunch of different, connections put together.

There is GitHub, the Linear CLI and and the Linear API.

Linear doesn't have a command line interface.

Supabase connection, Fly.io connection, and then also a couple of default stuff like what's the default organization, what's the Linear team key, what's the Supabase default organization.

It just walks you through that, right?

And then that's it.

Now the interesting thing about all this is if something's not working, you can also just, launch dovetail doctor and that's it.

Now if I want to create a new project from scratch, what I have to do is I just say dovetail init and then project name.

I'm not going to start it now because I just started— I just ran it before.

So it starts it.

Let's say the project is dovetail live.

And then what happens, it runs the authentication, right?

It asks me to confirm if this is the repository, do I want to make this public, what's the Linear, team key, what's the Fly.io region, etc.

And then it configures a project and then it creates the scaffolding.

So it creates a simple PernStack application code, like the basics are set up, for running a an app that can be hosted on fly.io and whatever.

It's, it's a container.

You can build whatever you want in it.

Then you— it creates a GitHub repository.

So creates a scaffolding, creates a GitHub repo, creates a Linear project, creates a Supabase project, creates a fly.io app, then installs all the dependencies, wire everything together, set everything up.

And then once it— the whole thing is put together, the last step is it installs a bunch of hooks to Claude, right?

right?

And then if I want to, I can go ahead and take a look and see that here is my scaffolded project that I just created.

I can go to Linear and see my Linear project was just created right, with a couple of basic issues.

or I can go to Supabase, and I don't think this is going to log it— load it because that's the project URL.

But let me it for you.

So I go to my project here And as you can see, the Dovetail Live project, which ends with XYLE, as you can XYLE.

So this was just creating and created.

And then, if I go to fly.io, you can see that there's Dovetail Live staging and Dovetail Live production.

It's still pending because, it hasn't been committed yet.

Now I have this here, and and if I want to, I can just go over to, Dovetail Live, and then let's see what's what.

So I just go cd dovetail-live.

Let's go over here.

There you go.

And I just can— I can just say dovetail status.

And I can see we don't have an active issue, so I can start running stuff here like dovetail check issue, and then it checks all the issues.

Are there any open?

No.

So I'm going to create a new one.

What's the issue title?

And let's say I want to create a DIY gardening landing page.

—no description, medium priority.

So here is the manual mode, right?

And it doesn't even work, right?

Okay, so what we can do is I just go to cd dev— live And then what I can do is, you know, I can check Dovetail status.

Status— it shows no active issues.

So there are a couple stuff that I can do here.

Or if I don't want to do stuff manually, what I can do is I can just launch Claude.

And then when I launch Claude, what actually happens is that because I installed a bunch of hooks, Claude now automatically runs those hooks every time I want them to run..

So for example, every time a session starts up, there is a Dovetail, command that runs which gets us all the— what's the project, what branch, branch are we on, what are the services, what are any issues, let's see what the commits commits are there, what are the latest updates updates on, on Linear, and that's it, right?

And then, no MCP servers are configured.

That's something that I will need to add to Dovetail so it automatically configures, uh,, Linear MCP server and Superbase MCP server and everything for you, so you don't have to deal with that.

But the idea here is that when I say build a, DIY gardening blog page, then the idea is that before I actually send a new— a prompt, first let's say if there is an existing issue— there is none, so it— the first hook fails.

So now it starts looking at the actual code inside the database— inside the code base, right?

And then it creates— it fills its own context, but it's not doing anything.

It's not changing anything.

It's just learning about your, your code.

It's learning about the the environment it's in.

And it says this is a Pern stack with a Vite and React, etc.

So now it understands What's up?

And then the idea is that all of these things— this is done automatically by a hook.

So the idea here is that Dovetail has a session start— start hook, has a user prompt submit hook, has a pre-tool use hook, and the post-tool use hook.

And that means that that every time a session starts, check what's, what's up with the project, get context on the last work.

When I send the prompt, double-check if we are on the— we are, on, on an issue.

Is there an issue?

Is it the project?

Like, do we have anything like that?

And then before there is a pre-session— look at this, there is a pre-to-use hook that runs before— it shows error but it's not an error, so it runs before write action is and, and launches a sub-agent.

And that— or sorry, first checks if, are we trying to use a restricted tool?

Yes, the write tool, changing a file, that's restricted.

So let's see, what's the project, what's the main— oops, no active issue.

So we're going to block, block the, the, task.

And instead we're going to launch a Dovetail Sync Agent.

That job is to say, here's what the user wants, here is the, the project, here is everything about the project, and then figure out, do we need to create a new, new issue?

Do we need to create a new branch in GitHub?

Like, do we do?

And it just gets everything done for you together.

there is a current issue with the hooks.

I'm— that's what I'm working on right now.

it's not very stable at the moment, so— because I think the agents weren't installed for some reason.

But then the agent gets everything done for you and then creates a new branch on GitHub related to the issue, so the two are synced together, and moves to that branch.

So you're not going to change anything that's working.

And then once it's done working, it triggers the postToolUse hook, that basically does, okay, so we just did this, is this issue done?

If not, then we keep working on this.

If it's done, I'm going to create a pull request, document everything in Linear, and update the or create new issues if needed.

And then, and only then, I'm, I'm done, right?

And that means that I move forward, I keep building stuff, and then, Dovetail sort of cleans up in front of me, like clears the pathway in front of me, gets me the context I need, and then it also cleans up after me.

And because of the branch protections on GitHub, and, and the pull requests and the document— heavy documentations and the automatic deployment, everything's pretty automatic.

And there is literally zero chance that, cloud code this way can actually like fuck stuff up, for real, during development.

And the interesting thing is, because this way the whole context is now externalized inside the commit messages in GitHub and the linear documentation, now the agent always has really good context even if, if it doesn't have that in its memory.

So I can just say, hey, tell me what to do.

I want to build this Alfredo OS Cloud and tell me what are the stuff we should do.

And then it says, hey, so we have 5 milestones.

Milestone 1 requires 6 steps.

And I actually said to Claude, fine, in that case, launch 6 agents, for all of the— my— all of the milestone steps, make them write, whatever needed to be built, independently.

And then launch another agent that orchestrates it and tests everything.

And then because the hooks deterministically enforce what to do and how to go through that, it always works the same way.

So yeah, that's what I'm working on right now with Dovetail, and, I'm pretty sure that I can, I can release it soon.

It's— again, it's not stable, it's not working, but anyway, I'm going to release it anyway.

yeah, so where are we?

Okay, so that was Dovetail.

And So you go into here and then you can actually look at the, issues and everything that's in here.

So everything that, that I'm building is documented in here.

this documentation is done through like an earlier version of Dovetail.

So this is fully automatically built, the whole Linear.

I never open Linear.

okay, so let's go back.

So the next thing is Joe.

Now Joe is interesting because it's a voice agent that I'm building for a construction company, and, we have a couple of, of stuff that we need to, adhere to.

One, Joe needs to have— there you go.

So Joe needs to have a less than 10 cents, per minute, cost, also has to have a less than 500 milliseconds latency, and, and also has to— we have, we have about 30 different tasks that, the client said they want to have chosen.

We need to have at least 60% coverage and we need to have at least 80% success rate, right?

So again, the kind of the problem is that because agents are doing stuff on their own, achieving this is actually not very easy.

so at first what I was doing— there was also a, an evolution to this, right?

So at first what I doing is— let's go here.

So at first I figured I would build, I had an NA10 chat agent before we said we would want to have, a voice agent, and I moved the NA10 chat agent over to a custom built, app.

So I actually built a voice agent using the OpenAI, real-time API, which was expensive, but it did the job really well.

And there was one big problem that we couldn't really do anything with it, which is Joe has to be able to do stuff but also has to be able to interrupt me.

So this is is actually an interesting problem with, with voice agents, right?

Because it's usually one-directional.

I call the voice agent, I say, hey, I want you to do this and that.

Okay, I'm on it, wait for— wait a second.

And then it keeps doing it, or it gives me a call and we start having a conversation, but it's all happening synchronously.

And what I want to do is, let's I'm mid-call Right?

And what I can do is I can say, okay, hey Joe, I want you to do this and that.

Let me know when you're done.

Bam, hang up.

And then when Joe finishes, that could start another trigger that says Joe gives me a call and says, hey David, I'm done.

But what happens if I want that happen mid-call, right?

What happens if what I want to do is say, hey Joe, I want you to do this and that and then says, okay, I'm doing that in the background.

Is there anything else you want to— you want, want to discuss.

And while we're having a chat, if, Joe's background task is completed, whatever we're done— and whenever I stop talking, it's like, Joe, okay, thanks for that.

By the way, I just got the message.

Here is the result.

Do you want to hear the result of the previous query?

That kind of interaction makes the whole thing really, really, realistic, and it's very, very hard to make it work.

So I started working on, on, on a custom-built app But then the whole logic was a bit, challenging.

And then I moved the whole thing to the ElevenLabs conversation agent, conversation agent, which does everything perfectly except for this, this bit.

ElevenLabs agent cannot deal with the interruption stuff.

It cannot like have proactive mode for any voice And then I moved over to VAPI, which through the VAPI API, it is possible, it is possible, but you need some extra plumbing, right?

But need plumbing, because basically what we had in here was we had Joe— let me, let me just explain.

So Joe was a VAPI agent, and then what I built first was Joe had N8N workflow, right?

And that N8N workflow was called through MCP tool— MCP call.

I also experi— experimented with an MCP call or a direct function call.

it doesn't really matter, whatever works.

But what happens is that I'm having the conversation with Joe.

So user says something, and then Joe says something back to the user.

But also routes the channel— routes the task back to this N8N workflow.

And then whenever the N8N workflow is done, that workflow then calls the Joe, agent, and Joe proactively starts talking to the user, like mid-sentence, right?

Now the challenge with this was with, as always N8N, so I was looking at different ways of making it work, and, the big problem that we had with this is even inside n8n, you know, it works really well, but it, it took a lot of debugging.

But the really, really big problem was that Joe's task list here, right, we needed to have 60% coverage and 80% success rate.

So what I would do is I would take a task number 1, task number 1, and then actually take a look at all the tools Joe can have, which is just, you know, business data, MCP connections, via MCP connections.

There was an ERP system the company uses.

And basically a task needs to have a set of instructions, in sequence to complete.

Like, for example, step 1, tool call 1, step 2, tool call 5, and so on.

And I want that to happen exactly like that.

And that's when we had the challenge, same challenge that I was dealing with Alfred, which is if I just give it as a prompt, then sometimes Joe will do it that way.

Sometimes Joe will not do it that way.

Which is a problem, right?

Especially because what if, this tool call 1, tool call 5— what if that's not actually how it works?

the first idea I had was that we had a SQL database connection, so every tool call would be an execute SQL tool call.

And the idea was, is is that send— I would send the prompt And then once I send the prompt, Joe the agent would understand or translate— translate prompt, prompt to a SQL query, run the query, return answer.

Which seemed nice, but what if I want the financial projection based on the last 2 quarters of data and I want to know how much bonus I can get out of the company for Christmas?

I— that's not a— that's not a simple solution.

There's a lot of very complicated SQL queries that needed to run, and I was just kind of waiting for stuff to happen for minutes, and that wasn't— wasn't really useful.

That's when client said that actually we should have sort of a less than 2 minutes, completion in order for make it worth to have a live conversation.

So then I started translating these tasks into tool calls.

But then the question is, how do I do that?

Do I create an 8N workflow, like, an 8N workflow per task?

That's not very scalable, right?

Every new we would need to create a new workflow.

So that's not what we want.

if I just use the prompt, it's unreliable, unreliable.

so what can we do?

And then turns out that we needed to have an, a new MCP connection for the ERP system.

And that was really interesting.

That was, not a simple problem because what I had to have is we had the old API for the ERP system which was not built for agentic execution.

And also it was not built for human work, right?

It was a technical API, so it was following a technical logic.

I needed to build a new API for operations.

So instead of having an API for different database operations, I would have an API for, I don't know, updating a— like creating a status update or notifying stakeholders in a project or something like That, right?

We're creating a financial projection.

And then I ended up creating a, uh— I think there's 84 different API endpoints and then turned every endpoint into an MCP tool.

And that means that our Joe MCP connection can now, understand those 48 actions with schema.

So it doesn't have to always figure out what the query is.

It just calls that API endpoint.

But in order for that to work, I would need to basically translate task number 1 to a sequence of tool calls from that one— from that 48, bucket.

Like, how, how do you express task number 1 as a sequence of these 48 tool calls?

And once we had that we— the system now works in a way that I just ran the evaluations yesterday we're exactly there.

So out of the 30 tasks, we have 80 task coverage.

there are— if we add, if we add 3, extra MCP servers, stuff like Gmail, Weather API, and that sort of thing, we actually go up to 27 task coverage.

So 60% goes up to what, 97, 95%?

I don't even know what the percentage of that is.

Anyway, so we're almost there.

And then, we also had a median 80% success rate.

That's, success rate in the evals.

that— I think it's actually higher, but there were some logging issues, right?

Like, not all the MCP tool calls were actually logged in the evals.

And the way it works, it did— it does have— so Joe has a WAPI custom prompt and, custom system prompt.

And there are two more interesting aspects of it.

One is it runs on a Groq infrastructure, Groq inference.

It runs Llama Maverick, 17 billion billion billion parameters.

And, this gives us an exactly $0.1 per minute cost and the 475 millisecond latency.

So if I'm looking at these parameters, This works, this works, this works, this works.

This also kind of works.

I'm not— I think I'm not logging execution time yet.

So that's where I'm at right now.

so yeah, it's, there is one more thing that makes things faster, and this is this part, and that is the memory layer.

So looking at Looking at memory, I said user prompt, Joe calls Joe MCP, done.

What if I say after that, that, save what happened to memory, both what the user asked, if that was, good and the actual output.

And then I would change the process as well.

So I would go this and then also, get memory, right?

So instead of trying to do everything right away, I would want Joe to just get stuff from memory.

And for that, I'm using Memzero, which is pretty cool.

And, they just got a bunch of funding, so I'm pretty sure they're to be raising prices soon.

There is a startup package.

And, yeah, basically, you go to Smithery, and inside Smithery there are a bunch of— there are a bunch of, memzero MCP servers.

And there's also an official one, but honestly, it wasn't working.

at least it wasn't working for me, and I don't know what was the issue, but all the MC— all the memzero MCP servers had the same issue.

So I built one for myself and you can find it as David AI.

that's what I built, and it basically only has two tools.

It adds a memory and it searches memories, and that's it.

So it does exactly what we want it to do.

I say something, search my memories to see if there is a relevant bit, and then if no, call the— calls the Joe MCP and then says what happened.

If there is an actual then just immediately answer it without moving forward.

That actually sort of memory caching logic that makes things work a lot faster.

So that's the Joe project, and I'm hoping to hand it all— hand it over soon, because we are at the last stages of this work.

And then there is the last project, which is Jig, and, that's, that's the most interesting one.

Right, because JIG is nothing else than— is a cognitive assembly line.

Now this is interesting because there is again same problem like N8N versus agents, right?

I've been, I've been talking about it a lot because N8N, with N8N, you have, you have deterministic plumbing.

So, but you have deterministic workflow and manual plumbing, which means that if I want to create a 5-step process, I actually need to create a 50-node workflow because JSON expression, aggregate, merge, custom JavaScript, whatever.

And then if anything breaks, the whole thing breaks.

And then N8n also cannot just resume from that step unless you're saving executions properly.

And it's, it's just very complicated and very So, but if it works, right, if it works, it's great.

If it doesn't, you're debugging at 2 AM and you don't know why.

And that's, that's the big problem.

And also it gets very, very complicated.

Like, like the graphs are so complicated.

And then you have— you look at agents, which is, you know, ChatGPT agent, Manus, whatever.

And then they are probabilistic, so they drift off, off and hallucinate, but they can, can, be resourceful too.

Right?

So if, if let's say your JSON is broken and N8n breaks, Manus or ChatGPT agent or Claude code, it would just figure it out.

So hey, it looks like it's broken.

It looks like there is an extra comma there and I need to remove and that's it.

And you know, I don't want to be debugging at 2 AM because of an extra comma.

I want the agent to automatically figure it out.

So what happens here is, Do you have— you have a bunch of nodes.

This is how an ADN works, right?

You have a bunch of nodes, that's it, and then you also have a trigger, and that's it.

That's how an ADN works.

And then You have an output at the end.

Okay, so, the agent works differently, right?

The agent just sits in the middle and just does things as a black box.

And you have zero control over what's happening.

Or you can build an N8N workflow in a way that it does stuff similarly, like this.

It triggers an agent, then it triggers another agent, then it triggers another agent, and then it generates generates the output.

That's actually not a bad idea.

But then the problem is, basically the, the payload.

So let's just add a bag, right?

Here's our payload.

So all the information that we send over here, these are all, completely custom designed, right?

Inside N8n, you need to tell what are you sending off to the next agent.

What's the context that it should be getting, right?

So you need to be manually designing every single bit.

We— however, inside an agent, it just gets an idea and then it figures everything out on its own.

But if you want to build AI agents inside n8n, you have to still do the same plumbing thing.

So that means that even though it might work, you still need to, you know, deal with JSONs and commas and whatnot.

And my idea was that what if we had this logic, right?

What if we had this logic, but whatever the payload is, this would be managed somewhat— I don't know, somehow it would be managed differently, would be managed, with purpose, with intent.

Like, how would that look like?

How would, how would it look like if— oops.

How would it look like if I wanted to intelligently pass on context so the agent can actually understand what the other, what the previous agent did, but in a, in a, in a very compressed way so it doesn't bloat, doesn't get bloated.

And that's when I went to Claude code because I felt, okay, so what happens If I start Claude, let's say I would start Claude code, I would give agent MCP tool number 1, and I also give it a simple prompt and, prompt for a single task, right?

And then whatever the output is, I don't give a shit what the output is, just send everything over to the other agent, figure out what the ideal output should be.

And then the next agent would do MCP number 2 with another prompt, single task number 2.

And that means that basically we are launching new agents for every single task, just like what we did with NA-10, but then the context is decided— it's just everything is just shoved over together from one to the— from one to the other.

And here is the problem with this, right?

The problem with this is that basically it's like you launch Claude, Claude code, you turn on some connections, you have— you let it run, then you turn off those connections, give another prompt but new connections, and then you run it again and again and again and again.

And because it's the same session, it's actually very hard to make it so that, you know, you either have to manually turn everything on and off all the time, or, if you don't want to do that, then you need to figure out how to, how to restrict tools per each agent run.

And you either— this— to solve that, you either have to solve the N8N problem.

So instead of sending everything from one agent to another or using the same agent again and again, you need to figure it out manually what to send over, or you need to have a system of— that manages context between these agents at a very, very effect— effective lossless compression while also orchestrating the deterministic part of do this task, this is the tool you use, this is the the input I'm expecting, this is the context, this is the output I'm expecting, and that's that's it.

And, and then as those things run, then the agent itself, basically does everything, which means that the macro bit is completely deterministic, the micro bit is completely agentic.

And that hybrid between, managing context was really important for us because the idea was, is what happens if this is a human and not an agent?

What happens if I want to replace one with another?

Then how do I feed the right context to the human without overwhelming them?

It has to be— and this was one of the key ideas of Jig— that it has to be intelligence agnostic.

It shouldn't matter who the human is or who the actor is.

Like, is this a human?

Is this an agent?

Is this a manager?

Is this an engineer?

Like, everybody should able to to it.

And And the way we did it is we created the, Jig DSL, which— let me start with another thing.

So we created a framework, the IKO framework, which really just builds on stuff like Jobs to Be Done and other frameworks.

The idea here is that in an AI-native world, every task you do inside a business can be described by these 4 things.

Let me explain.

First big statement around JIG is that every operation is a CRUD operation.

Everything you do in your business is a CRUD operation.

You are creating, reading, updating, or deleting some some value in some database, even if that database exists in your head.

so the question is, how do we get access to all the databases that we need to do, and how do we actually describe these CRUD operations?

And that's when we came up with this IKO framework, which means that in a truly AI-native business, you would have— every CRUD operation has an intent, has some relevant context a specific action you do and the specific output, right?

if you remember, it's like the Jobs to Be Done framework says that you don't buy products, you hire them to get a job done, right?

Me wanting to get a job done is the intent.

Why I want to get the job done is also part of the intent.

And also Once the job is done, how do I know it's done?

That's my output.

And getting it done is the action.

And then how to get it it done and what you need to get it done is the context.

So I— ideally, every action inside the business can be described by this framework, which means that, you know, we have a specific action.

Let's say you have a task.

That can be described with this IKO framework.

What happens if you create a workflow which have 3 tasks— 3 tasks in it?

The workflow itself can also be described with IKO framework.

And then what happens if you have entire business units that have, I don't know, 5 workflows in it?

Then again, that can be described.

So it's really like a fractal pattern.

And that's why we called it IKO fractal.

Now, in order for this to be translatable into, agentic work, we really needed to have a very specific, very efficient compression of information that is understandable by humans.

And that is the Jig DSL.

It's a YAML-based, YAML-based language which really just describes these intent, context, action, and output in a structured format.

And then once we have— once we created that, right, so we had the intelligence-agnostic idea, which then led us to the IKO fractal, which then led us to the JIG DSL, which then led us to the idea that ideally I should be able to create, a database, right?

A Jig database— Jig database— that where I can just take a workflow description that's described in this YAML, and then every, every part of this YAML is translated into some database entry.

And once I have that done I gain a really interesting thing because now I can orchestrate work through a database instead of through code.

n8n orchestrates through code, Make orchestrates through code, Zapier orchestrates through code.

It's not very durable.

So if I, if I orchestrate everything through a database, which is execute task in, that has an ID ABC in this database, and here is all the configuration pattern of that inside this database, then it becomes very durable if we actually log every act, every step of the way.

So we would have like a run log in the database that says, okay, so step number 3, this is what was the input, this is what happened, this is what was the output, then we got an error.

So instead of redoing everything, I immediately have everything saved in the database that says it failed at step number 3.

We just want to figure out how to make it work.

So inside this Jig database, right, I would have— I, I would have tasks somehow explained, tasks explained.

I would have workflows explained.

Oopsie, let me just Okay, so we would have tasks which we call stations and workflows.

And let me explain this.

So we call them stations because when it— Henry Ford created the assembly line, what happened is that before Ford, before the assembly line craftsmen— craftsmen owned production end to end, right?

And then after the assembly line— after the assembly line, factory workers owned a specific task.

Now, why did that happen?

It happened because Henry Ford, did the research and a study on his own factory and realized that because a craftsman was owning a longer process, they had to work around the factory.

So if there was somebody who was working 10 hours a day, they they they actually were pedestrians in 40% of the time.

It's not factory workers, it's pedestrians.

Right?

You walk around for 4 hours and do actual work for 6 hours.

So instead of humans going the work, he asked, how do I eliminate people being pedestrians?

And the answer was, let's go it the other way.

Let's not have people to go to the work.

Let's have work to come to the people.

And that was what the assembly line became.

Now, how does that translate?

To, knowledge work, right?

Inside knowledge work, you have problems, right?

And that means that you own the problem end to end.

So as a knowledge worker, you have a series of problems that you need to keep solving all the time, and you own it.

You have full ownership of the problem.

You need to know when the problem arises.

You need to know when the problem needs solving, when problem needs escalating, you need to follow through, you own the problems And then the big problem is that problems have lots of smaller problems, lots of smaller problems, that require different context.

So then this, this is the key, key learning here.

Is that we had pedestrians, pedestrians for factory workers, right?

We know that they weren't as productive because they were being pedestrians.

They were working around different, parts of the factory.

What's the— what's the knowledge work equivalent of that?

And the knowledge work equivalent of that is context And right, because different problems require different context.

So if the solution for pedestrians, for making people not pedestrians was to make people make, move work, not right, then the idea here is that we would move context, not people.

So, the cognitive version of an assembly line is that the context always comes to you the same way, but the task itself never changes.

And that's a big problem because human work is messy, it's, it's random, and knowledge work is messy and is random.

So we really need to figure out how we can manage context, and that's, that's the most interesting part of Jig, how we manage context.

I'm not going to go the details.

There's a whole context layer and the context ledger that connects everything, and, but the point is that you have this Jig database that creates the foundation for all this.

And if I move here, so here is a specific, Jig, run.

As can see, there was an actual execution by an agent.

It cost 2.86 cents.

we had a specific type.

Here's a number of tokens that were created.

And what you can see here is the full execution log of what the agent did.

And we had what was the intent.

I was like, search my memories about David and report findings.

Here are the tools that were used and how many times, you can also use— see what connections were provided, what was the actual prompt, that we gave.

And then here's the context blocking, the context ledger.

Basically, after every execution, Jig analyzes itself and says, okay, did we actually achieve the intent this work, and how confident am I that my answer is the right answer?, and then it also writes a report, that's human-readable for later.

If I say let's create a file, it saves it to an artifact as well.

So, and then I can take a look at all the workflow history as well.

And then there were a bunch of eval— evaluation stuff because, the idea here is that if you have this, you can use Jig to run evaluations.

You can use Jig to do a bunch of stuff.

So Yeah, the the interesting thing is now we have a Jig MCP server that creates these things, and basically the execution part is following this, right?

So the Jig logic transports the context, and every agent is a Claude code agent.

So it's like— or a Claude agent built on a Claude agent SDK.

It It spins up a Claude agent gives it— gives it the tools it needs, everything, and starts with the— with the workflow.

Then it generates the output as specified, in the jig, and then calls the next agent.

The next agent forks the previous Claude agent, so it has all its memories, but now it has a different task, it has a different intent, a different, prompt, different tools, different access.

It's a different one.

It's kind of the same same but different.

And then it keeps forking the Claude agents until it gets to a point it reaches the final output, and then it does the final output.

creating JIGs, out of SOPs is a really powerful thing for now because, I got a Loom video for— that would last 5 minutes from, the operations manager of the client, and on how they do reconciliation of transactions at an e-commerce company.

And I fed it into this JIG system.

I have an, architect that can transform these raw translations or raw transcripts into JIGs and then implemented it.

And like with a single one-shot attempt, we got 95+ accuracy in the completion.

And we're not creating new agents, we're just using existing ones.

And if you have a JIG MCP, then you can actually, actually, run everything from Claude or ChatGPT or whatever.

So like there are a lot of stuff that like between different projects because they're all trying to kind of work in the same problem space.

the interesting thing about, about Jig is, a last— the latest thing that I built is that I can, I can create a station and run it and then like as a temporary station which really allows me to just create short-lived Claude agents as part of a workflow and save all the context they generate.

It's getting very complicated very quickly.

but so this is the other project that I'm working— I'm very happy about this project.

This is a really cool project.

yeah, so these are, these are most of the projects that I work on.

And then there are a couple other stuff, like the boot camp is returning next week, and then I also have a fun project about— I think it's here— the No Code No Clue process, which translates n8n workflow JSON files into tutorials and radio plays.

And I started building an actual, workflow to generate the content.

And inside n8n, it was very, very complicated.

and ultimately I ended up using my Dovetail-powered Cloud Code, Code, process and basically built the whole system, I don't know, in, in less than an hour.

So now what it does is this.

So basically it runs a simple dashboard, but it also works from the terminal.

So, I have Launch that with a simple command.

It says npm run dashboard.

And then what I have here— I know I call everything Alfred, I should really stop that, stop doing that.

So what happens is that when I start running it, it starts running through a bunch of steps and it starts generating— like, it starts going through a 13-step process.

And then if some error— if it contains or encounters some errors, it can pick it up and continue on from that later.

And what happens is that it takes a look at the workflow and it understands the workflow.

So it was— it took a JSON file that was Jackie, an AI assistant.

I got it from the N8N Template Marketplace.

And then it actually tries to understand what that workflow does.

It creates an analysis, and then it creates another analysis, which is, you know, where does this actually solve a problem?

What's the context?

where, where is this an overkill.

So it generates some extra context, and then as a next step, it starts creating a script.

So it's like, okay, let's try to generate a— hold on, yeah, there was an error there.

There you go.

So step number 3 is it actually creates a script, metadata.

There is like a sitcom episode generator which has like a guide, and, I can walk you through that in a minute.

And then it generates the pack, and from that it generates a script.

And now we have the script here, which is a pretty long script for a sitcom.

and then I'm like, okay, next turn that into a JSON.

And, and once you have that JSON, I want you to go through each and every one of those and then generate the actual radio play.

So turn the script, we have, you know, voices assigned to different persistent actors, permanent actors, and then there are random voices for actors.

And then it generates something like this, which is like pretty cool.

It's a full radio play, here.

And you can also check the one on the Notion Tripling workflow, and it's fully automated.

11Labs now has the V3, model available the API.

So it uses FFmpeg, MPEG, MPEG to generate all the, dialogue, blobs.

And then, it generates one big audio file for the radio play and saves it.

And then it generates some metadata, some SEO stuff.

And then once it has everything, it takes the actual workflow and then an actual tutorial.

And, And then it— the last step is that it, posts it to, Ghost as a blog article.

And I'm still working on it, but I will probably turn this into like an automated regular n8n tutorial, article sequence, maybe once a day.

It will help me with SEO, and it will probably also, give you guys some ideas on, on how to do stuff on n8n if you still want go down that road.

So you can see, you know, there is like— okay, here's the source, what tools are used, setup time, difficulty, time saved per month, and then there is the, the tutorial.

So I'm still playing around with it, we'll see how it goes.

But that's kind of a fun side project that I'm doing.

So, okay, the raw recording is almost 90 minutes now, so I'm gonna talking.

There's a lot of stuff that I'm, I'm working on right now, as you can see, which, I just wanted to start talking a bit more about that.

So I'm going to— I'm going to share the linear document, the linear roadmap links, and I'm going to just start uploading YouTube videos separately per project and then also sending out different, different emails like on a weekly basis.

So thanks for watching.

If there is any questions you have