DEV Community: Ilbets

Your machine has the perfect agentic setup! Use it anytime, anywhere!

Ilbets — Fri, 13 Mar 2026 14:40:51 +0000

TaskSquad.ai – talk with agents on your machine, create teams, collaborate, anytime, anywhere

Two weeks ago, before going on a long break, I wanted a way to keep using my home AI setup remotely (this was before Claude introduced Remote Control).

So I hacked a simple app: a daemon running on my Mac that connects to an inbox where I can chat with an agent. I vibecoded the whole thing just in a few hours.

During my leave, it turned out to be surprisingly convinient. Most of my pet projects already have a CLI + keys environment set up, so agents could deploy things easily. While waiting on the ski lift, I would ask the agent to tweak some UI and redeploy the app. By the next ride up the lift, the change was already live.

That prototype only supported Gemini, but it made me realize the idea was fun and useful. So after coming back, I kept hacking on it.

That’s how TaskSquad.ai was born.

How it works:

Open the portal and create a project

Add agents (one agent per CLI tool + folder path)

2.1. Add friends to your project*

Install the daemon on your machine
Copy the generated agent config into ~/.tasksquad/config.toml
Login to the tsq daemon

Run the agent

Agents currently support CC, OpenCode, and Gemini. _Codex and OpenClaw support is in progress. Once running, you can open the inbox and send tasks to your agents.

The daemon keeps sessions alive, supports multi-round interactions, and lets you preview raw CLI logs.

You can run multiple projects with multiple agents. You can also invite friends and connect their machines to the same team. As well you can also shut it down or reset all sessions from the portal directly.

This is still an early prototype — feedback and pull requests are welcome!

github.com/xajik/tasksquad

A New Era of Agent Native Applications

Ilbets — Sat, 24 May 2025 14:09:31 +0000

In the next five years, 99% of companies will have agents for their services. That will open up a new world of agent-to-agent communication—an agent economy and even an internet of agents. Agents may not completely replace traditional apps, but they’ll take a huge market share.

Next time you want a new dining table, it might be as simple as asking your Agent app. It’ll message a few store agents, find one you’ll like based on what it knows about you, and place the order.

So, when I started working on Terminal1.app, I wanted to imagine that future. I asked myself what an “AI native” company might look like—and built it, agent-first, from the ground up.

Idea

In late 2024, I had a three-hour layover in Munich. I was alone, eating dinner, and thinking about how much time I’d wasted in airports that year. I’d taken around 60 flights for work and leisure. That felt like a lot, but some of my friends, especially those in sales, fly much more.

I sometimes try to work, code, or read. But let’s be honest — getting anything done in an airport isn’t easy. I started wondering: how many people like me are sitting in airports right now, looking for something meaningful to do?

That’s when the idea struck me — what if there was something in between Tinder and YC’s Co-Founder Matching to build business connections during travel? An app that connects airport business professionals based on their shared interests in the airport.

Lastly, meaningful social connections are key to personal happiness. I’ve met many people who later became close friends at events and gatherings. Sometimes we’re so busy with work and chores that we forget how important it is to be around people we care about — and who care about us.

Terminal 1

Terminal1 connects traveling professionals at airports based on their LinkedIn profiles, flight times, and interests — so they can network while they wait. Transform airport time into business opportunities.

1️⃣ Log in with LinkedIn to create a profile

2️⃣ Send your CV to create a detailed profile for matching

3️⃣ Share your upcoming flight details

4️⃣ Review and accept your match 24 hours before the flight

Communication in the Agentic Era

One thing that changes in the new Agenting Era is how we communicate with customers. You don’t need fancy designs to turn simple user needs into system actions. Let the agent handle it for you ✨.

The primary communication interface for Terminal1 is email (maya@terminal1.app): send your CV, forward flight tickets, or reach customer support.

While there’s also a web interface, it’s intentionally simple, as it’s not necessary in AI-Native app.

However, I found it useful to address trust issues when working with AI agents.

From the 50s to AI Native

From day one, I wanted to build an AI Native system. But first, I had to decide what that really meant for myself. Since agents act like humans, I imagined what Terminal1 would look like as a company built in the 1950s, where everything is handled by people.

It starts at the reception desk — a scene we all know from old movies. A mailbox, a stack of documents, and a receptionist asking, “How can I help?” They take your request and promise you’ll get a reply by mail in a few days.

They sort each request into the right box. Later, an assistant with a trolley cruises through the office, delivering each box to the right department. Your CV goes to the CV review team. Your flight tickets go to the flight review team. The matching team checks upcoming flights, compares profiles, and finds a good match. Then they pass it back to the assistant, who brings it to customer support. Finally, customer support sends you a letter by mail about your upcoming meeting on your next flight.

And that is exactly what I did.

Design of the Agentic System

Terminal1 is built around a network of asynchronous agents. Everything starts and ends with an agent. The system is designed to be modular, where each agent focuses on a specific function, passing tasks along a dynamic pipeline.

Reception agent — identifies the user’s intent from incoming messages and routes the request to the right agent. It’s the starting point of every interaction.
Ticket agent — extracts, processes, and organizes flight ticket data such as destinations, dates, and airlines, so it can be used in downstream matching.
Curriculum Vitae (CV) agent — parses resumes, normalizes the data, and prepares profiles for efficient matching with other users.
Customer Support (CS) agent — handles incoming support requests, retrieves relevant information, and triggers actions to help the ve user.
Public Communication agent — generates the final response to the user, translating system output into clear, friendly language.
Date Interest agent — understanding what the user is looking for in their match: partnership, investment, or job opportunities, etc.
Date Feedback agent — process feedback from the date
Matching Agent — create the best possible match for the date

There are also a few other agents that support these main flows, executing essential tasks like data validation, formatting, and cross-checking.

Agents

Each agent in the Terminal1 system is built using LangGraph. They interact with the system tools through the MCP, which provides access to databases, matching logic, and communication layers.

Some agents, like the Customer Support agent, are powered by the ReAct framework to support multi-step reasoning and tool calling to resolve more ambiguous or complex requests.

Prompts

Getting high-quality results from AI agents requires a lot of prompt engineering. Along the way, I learned a few key principles:

Order matters — Structure your prompt carefully. Put the most important context upfront.
Examples — Good prompts need great examples. They guide the model’s behavior better than instructions alone.
Chain of Drafts (CoD) — An effective technique to improve quality while keeping token usage low. Iterate in stages.
Models — The same prompt can produce wildly different results across models. Choose your model wisely.

Each agent uses a consistent prompt structure:

<Task> <Examples> <Customer-Context> <Real-Time-Context> <Agent-Identity> <Company-Identity>

User Matching Agent

Perhaps the most intriguing part of the system is how we match users. It all starts when someone sends us their CV. The CV agent parses it, extracts key information, and transforms it into a clean, normalized format.

AI-normalized profile summaries are stored in a vector store. This lets us run similarity searches based on meaningful parameters, not just keywords. The Date Intent Agent does something similar — building an ideal normalized match profile for each user based on their input and context.

The rest of the magic happens in a cron job that runs every few hours. It gets all the unmatched passengers flying in the next 12 hours and groups them by airport. For each airport and overlapping time slot, we will take each potential profile and compute potential candidates based on the “perfect profile”.

This matrix, together with users’ profiles and their date intent, will be passed to the Matching Agent to generate final pairs.

Finally, everything comes together in a cron job. The heavy lifting — grouping users by location and departure time — is handled by an SQL function for efficiency. The result is then fed to the agent, which processes each user group individually to evaluate and confirm the best possible matches.

`Multi-dimensional matching based on time, location, and customer context is hard. Pair matching is even harder. You need to look at what both people care about and what they offer. For example:

VC looking for an AI startup to invest in and an AI Startup Founder.
Recruiter from an AI startup and engineering looking for a new opportunity
Talented singer and music producer `

Each match has to be a win-win.

With more user feedback, we can build an “Elo score” to help prioritize candidates on very popular destinations.

Tech Infrastructure

The whole solution is hosted on AWS.

Tech Cloud

Originally, I vibe-coded the website with the bolt.new, but I quickly hit its limits. So I downloaded the code and switched to just coding in Cursor.

Give it a shot

Termiminal1.app

If you have any questions or suggestions, feel free to reach out at:

support@terminal1.app

Game Night Just Got a Digital Upgrade: The Deck

Ilbets — Sat, 08 Feb 2025 15:42:49 +0000

The inspiration for “The Deck” came from a situation many of us have experienced. Imagine gathering with friends for a game night, only to realize that nobody has the necessary cards. Frustrating, right? This dilemma sparked the idea of leveraging technology to create a solution.

The primary goal of “The Deck” is to provide a user-friendly and cooperative digital game environment for playing classic games that were usually played with cards on paper. One of the standout features of “The Deck” is its unique ability to assign one device as the “table” (a.k.a. deck). By placing this device in the middle of the group, all players can witness the real-time state of the cards. This adds a new level of immersion making it a truly captivating experience.

Game Flow

First, let's look at the result 👨‍💻. I ideated on what might be the perfect UX for such a solution and settled on the next steps (here we are using Android TV as the table):

Create the Room - use TV, mobile, table, or laprot to create a room.

Join the room. A device that created the room can participate as well, or just be the deck.

Start the game! As soon as you have enough players, the host can start the game.

In this case, TV is the host & deck. Players are using their phones to move and other people can observe game updates on the TV.

Implementation

Over a span of approximately four months, I dedicated my weekday evenings and weekends to developing three games: Tic Tac Toe, Connect Four, and Dixitt. Eventually, I released them to both iOS and Android stores. Here are some details on the implementation of the game.

Transport layer

Considering that I wanted to make sure that app can run in the local network and require bi-directional, low-latency communication between participants, the solution was quite obvious — sockets:

For MVP I decided to stick to go with socket.io. After a quick search, I found packages for Dart:

socket-client
socket-server

Game Room

The game room is the platform's base abstraction. Each game starts with a host creating a room and inviting participants and observers. As soon as the game constraints are fulfilled (e.g., the required minimum number of players), the host can start the game.

Creating architecture was one of the most challenging tasks. As I need to ensure that abstraction will scale well for various games

Components breakdown:

Game Details — it is a description of the Game and room IP. It is advertised in the QR code so clients can check if they support the game and can join;
Game Room — created based on Game Detail, it is the main orchestrator for the game, keeps track of participants, and controls game state
Game Participants — List of participants with some metadata
Participant profile — participant profile in The Deck, with user profile information
Game Board — base abstraction for any game
Game Move — board contains a list of all game moves that were applied;
Game Player — an entity that describes participants' role in the game, like “red” or “yellow” in Connect Four;
Game Field — representation of the game field, i.e. 7 by 8 matrix for Connect Four;

Room: create, join, start

Here is GameRoom lifetime:

The Deck / Table

The deck or table, as well as the client, subscribe to updates, the only difference is that the server cannot execute “move”.

You can play as well without a deck, in case you don’t have a spare device

Please note that Android TV devices serve exclusively as the “table” within the game.

Packages

From the beginning, I wanted to ensure that socket server code could be run separately and deployed in the cloud. Therefore, I split the app into 4 separate packages:

Common — shared DTO and utilities
Server — socket server logic, depends on Common
Client—socket client logic, depends on Common
UI — Flutter UI app package, depends on 3 other modules

Common, Client, and Server modules don’t have any Flutter dependencies and can be published as separate packages.

Using Alfred, I created a new app to run a standalone HTTP server that depends on the Socket Server package and allows you to create a game room, and connect to it via socket. This solution could be potentially deployed in the cloud to remove constrain on the local network.

Game State

One tricky part of any online game is to ensure consistency of the game state on all devices. To simplify the problem, I decided that only the server would be able to modify the game state. The client is only able to send a request to change state — move and listen for field updates.

The state is propagated via broadcast ( socket.io API) to all connected clients.

UI State with Redux

The client is merely a game field representation, it was quite an obvious decision to use Redux as an application architecture. Each game screen has two basic functions:

Draw Game Field
Send Game Move request

Sockets & Redux

The pieces come together to form the next flow:

When the user selects the Game, the app creates a Socket Server & Game Room and stores them on the host device;
At the same time Host device create a Socket Client and connects to the server running on the same device;
Socket Server broadcast Game Board to 2 clients (himself and another player);
Socket client receives a Game Board and propagates it to middleware;
Middleware update Redux game-specific state;
Game widget updates based on the new state;
Now the player can send a move request to the server, which is propagated via middleware & socket client to the server and GameRoom middleware.

Socket API

To simplify communication via socket, I decided to build a REST-like abstraction. Each message extends from the back which contains the path. The path is usually a /roomId/* or/roomId/gameId/*. When a client connects to the room, they will subscribe to updates from the specific room for the specific game.

class AppSocketMessage extends JsonEncodeable {
  final String messageId;
  final String path;
  final DateTime createAt;

  final JsonEncodeable data;

  AppSocketMessage.send(this.data, this.path)
      : messageId = Ulid().toUuid(),
        createAt = DateTime.now();

  AppSocketMessage._receive(this.data, this.createAt, this.messageId, this.path);

  @override
  Map<String, dynamic> toMap() {...}

  factory AppSocketMessage.fromJson(Map<String, dynamic> json) {...}
}

All data sent in AppSocketMessage comply with JsonEncodeable that ensures that it can be converted to JSON.

Cross-platform support

A significant benefit of using Flutter is that you can run it on multiple platforms, including Android and iOS. With M1/2 Apple chips supporting iOS apps, you can run The Deck even on your MacBook.

➡ Unfortunately, Tizen / Samsung doesn’t allow independent developers to release apps outside of the US. As for Apple TV- this is something I’m planning to look into later.

Design

I want to highlight that all assets in the game, including the app icon, achievement badges, player avatars, and Dixit game cards, everything were generated by Midjourney or DALL-E.

Hard to express how much time, effort, and money I saved leveraging generative AI 🧑‍🎨 Even tho, I spend a significant amount of time “fine-tuning” them in Figma.

What is next?

First of all, the power of “The Deck” is in the platform. ➡️ Moving forward, my vision is to abstract the game code and open-source it, encouraging enthusiasts to develop and onboard their own games. My goal is to ensure that adding a new game to the platform becomes an effortless process. If you are interested in joining early testing contact me at me@getthedeck.com 🤝

I want to explore new cross-platform connectivity protocols, to allow seamless connection with devices nearby. 🎮

Add AI agents to play with you when you are lacking a few players 🤖

Finally, I am intrigued by the prospect of Web3. Give players AI-generated unique NFT badges for achievements, open internal marker place, and incorporate bidding options for adult players with cryptocurrencies. Who knows what exciting developments lie ahead?🤓

Visit

Visit getthedeck.com

Download

Android
iOS

Source Code

Contribution is very welcome! 🤝 ❤️

Github The Deck

Tech Stack

List of tools used to deliver the project

Empower Your Email Routine with LLM Agents: 10X Efficiency Unlocked

Ilbets — Tue, 24 Sep 2024 14:28:12 +0000

Nowadays, almost every service revolves around communication, whether it’s plumbers, receptionists at clinics, or clerks in banks. Every day, countless people read emails, review attached scanned documents, and PDFs; and sort, organize, and forward them elsewhere. Imagine how much time we could save if we automated this process! With the advancements in Generative AI and Large Language Models (LLMs), it’s no longer just a dream — it’s possible now.

Problem ✨ Solution

You receive an email with a long thread of messages and attached files — many of them with random names. What do you really want? To quickly understand what the email is about and know what actions to take.

That’s where EmailSnap comes in. Simply forward the email to review@emailsnap.app, and EmailSnap will apply AI to analyze the email and its attachments, then send you back a new, actionable, and well-formatted response.

The processed email contains:

Title: [Priority] Subject
From: Sender of the email
To: Recipient
Highlights: Key action items in bullet points
Summary: A concise review of the email content and attached files
Attachments: Renamed to reflect their actual content

You need to be manually whitelisted to send emails to review@emailsnap.app

Magic, right?🪄 Now, let’s take a look at how it works

EmailSnap.app 📩

The implementation consists mainly of two parts: the underlying infrastructure and the LLM flow. Let’s start with the more interesting part.

AI Review ✨

For the LLM implementation, we use the LangChain stack: LangChain, and LangSmith. Despite not using LangGraph itself, I apply the same graph-like idea for executing EmailSnap’s LLM processing, as it requires multiple LLM calls with different prompts while using various tools, like saving intermediate states to a database and S3.

Out execution graph contains the following nodes:

Format Email: Reads the EML file and converts it into well-formatted text, handling threads and forwarded messages while removing redundant HTML tags and other irrelevant information.
Read Attachments: If the attached file is an image or PDF, we convert it to Base64 for the LLM to read the content. For PDFs, each page is converted into a new image, potentially creating a long loop.
Review Attachment: This node creates a summary with highlights and action items from each document, suggests the recipient, and proposes a better file name.
Email Summary: The final node combines the formatted email and the summaries from all attachments to generate a complete email with insights, action items, highlights, and an overall summary. After the final content is generated, we will send out a new email back to the sender including reorganized attachments.

Infrastructure 🛠️

To process emails, we needed a scalable tech stack, and after a quick search, I found AWS Simple Email Service (SES) to be the perfect solution. The flow works as follows: SES receives an email, stores it in S3, and sends a notification via SNS (Simple Notification Service).

My service subscribes to an SQS (Simple Queue Service) queue, which listens for SNS messages. From the queue, I retrieve a message ID and use it to load the email from S3. The emails are stored in EML format, which isn’t the easiest to process, but fortunately, there are plenty of libraries to handle that. This setup applies to a specific email address that you register with SNS.

Below is the most interesting part of the Terraform code to configure it:

# Setup SNS 

resource "aws_ses_domain_identity" "ses_domain" {
  domain = var.domain
}

resource "aws_sns_topic" "email_notifications" {
  name = "email-notifications"
}

resource "aws_ses_receipt_rule_set" "main" {
  rule_set_name = "default-rule-set"
}

resource "aws_ses_receipt_rule" "email_receipt_rule" {
  rule_set_name = aws_ses_receipt_rule_set.main.rule_set_name
  name          = "store_emails_to_s3_and_notify"

  recipients = ["review@${var.domain}"]

  enabled      = true
  scan_enabled = true


  s3_action {
    bucket_name       = aws_s3_bucket.email_bucket.bucket
    position          = 1
    object_key_prefix = "emails/"
  }

  sns_action {
    topic_arn = aws_sns_topic.email_notifications.arn
    position  = 2
  }
}

# Create SQS 

resource "aws_sqs_queue" "email_queue" {
  name                       = "email-processing-queue"
  visibility_timeout_seconds = 30
  message_retention_seconds  = 86400
}

resource "aws_sns_topic_subscription" "email_sqs_subscription" {
  topic_arn = aws_sns_topic.email_notifications.arn
  protocol  = "sqs"
  endpoint  = aws_sqs_queue.email_queue.arn
}

After that, we subscribe to the queue on the service side to process emails:

while True:
  # Subscribe to the SQS 
  response = sqs_client.receive_message(
      QueueUrl=SNS_QUEUE_URL,
      MessageAttributeNames=['All'],
      MaxNumberOfMessages=5,
      WaitTimeSeconds=20
  )
  messages = response.get('Messages', [])
  for message in messages:
    email_id = get_email_id_from_sns_message(message)
    eml = fetch_email_from_s3(email_id)

# Find email ID from the SQS message
def get_email_id_from_sns_message(message):
    body_string = message.get('Body')
    body_json = json.loads(body_string)
    message_string = body_json.get('Message')
    message_json = json.loads(message_string)
    mail = message_json.get('mail')
    email_id = mail.get('messageId')
    return email_id

# Load and parse Email from EML
def fetch_email_from_s3(email_id: str):
    response = s3_client.get_object(Bucket=EMAIL_BUCKET_NAME, Key=f"emails/{email_id}")    
    body = response['Body'].read()
    return email.message_from_bytes(body,  policy=policy.default)

Besides that, I set up a MySQL RDS and an EC2 instance to run a Dockerized service. I chose this setup for convenience, ease of debugging, and to have more control over the running machine. However, in the long term, it makes more sense to migrate to Fargate for better scalability and management.

SES Setup

Setting up a Simple Email Service (SES) requires a few manual steps after provisioning the infrastructure. Once your infrastructure is in place, follow these steps by accessing the SES dashboard:

Navigate to Configuration -> Identity -> DKIM and press Generate.

Copy the CNAME records to your domain’s DNS provider.

Add an MX record to your DNS provider with the following details:

Name: Domain
Mail server: 10 inbound-smtp.us-east-1.amazonaws.com (link changes depending on your region)

Open Email receiving and activate the rule: default-rule-set.

This setup works in the SES sandbox. To gain production access, you will need to apply for production access from the SES homepage by selecting “Get Production Access.” AWS may require you to justify your use case and potentially ask further questions.

Note: You can receive emails without the verification process.

Sample

Finally, let’s take a look at a real example. I took an MRI report in PDF format from an online source, sent it to one email address, and then forwarded it to review@emailsnap.app. EmailSnap generated a new subject, highlights, and summary. It also extracted the recipient from the PDF — Dr. Ross Banner — and finally suggested a new file name: Regina Doe MRI Report, based on the patient’s name and procedure.

TechStack

Source code: https://github.com/xajik/emailsnap-service