Forward Deployed Engineer for AI agents.
I design them, build them, and change how the team works.

01 Problem

• Running Claude Code, Codex, and Gemini CLI at the same time, I could not see which agent was working and which one had finished.
• One agent, one task at a time is too slow. I wanted to run dozens of tasks at once and let agents pass context to each other.
• My notes and specs were not in a form agents can read.

02 What I did

• Agentty: a terminal that runs dozens of agents at once in split panes and shows each one's status. Shared sessions carry context from one task into the next.
• The core of Agentty is a forward-deployed view. Every team and work environment needs different agents, so you build a plugin for the situation and run a dedicated agent inside it. Reaching a new environment means adding a plugin, not rebuilding the tool.
• Cosmica: a note app that keeps everything in Markdown so agents can read it directly. It summarizes voice memos and links them into a knowledge graph.

03 Result

• I split feature work, tests, and reviews across Claude Code and Codex, and spend my own time designing the tasks and reviewing results. One person can now push several pieces of work forward at the same time.
• Routine development and operations work goes to agents, and I use the same setup at my day job.
• Meeting notes and memos are kept in Markdown, so a meeting recording becomes context automatically and leads straight into work. Cosmica and Agentty are connected to each other, which raised day-to-day efficiency.

01 Problem

• On Black Friday and campaign launches, a day's worth of traffic arrives within minutes.
• Reward payouts cannot be off by a single event, even under that load.

02 What I did

• Designed the highest-traffic paths to run on Redis. Counters, caches, and short-lived state never touch the database.
• Put Kafka between reward issuance and downstream processing, so a spike queues up instead of spreading to other services.
• Set up an AI-based workflow that automates coding, tests, reviews, and operations work, and rolled it out to the team.

03 Result

• The service runs steadily through Black Friday-scale traffic.
• Development and operations automation has become the team's normal way of working.

01 Problem

• Users in over 30 countries mine WKM tokens with their steps, and each mining event has to show up on a public explorer within seconds.
• Energy refills every hour and draws run on a schedule, so traffic arrives in bursts. People also try to fake step counts.
• With a small team, I had to lead planning, development, and operations together while keeping everyone moving in one direction.

02 What I did

• Designed the infrastructure on AWS: Elastic Beanstalk, RDS (Aurora MySQL with read/write splitting), ElastiCache Redis, Secrets Manager, and S3.
• Each mining event updates Redis through an async event, and the Next.js explorer polls it to show live mining activity. Read traffic never reaches MySQL.
• Stopped fraud and double payouts with HMAC checksums, replay detection, IP risk lookups, a daily reward taper, and pessimistic locks on stock.
• Partnered with XPLA, added Solana wallet payouts, and led the whole build including the iOS and Android apps.

03 Result

• Acquired users in more than 30 countries.
• Average app usage time above 3 hours, with users concentrated in Japan, then Korea, the US, and Europe.
• Sustained hundreds of concurrent users on average.
• 71 billion steps and 26.9 million mining events recorded on the public explorer.

01 Problem

• Order-book trading with live quotes and charts, plus liquidity pools, had to stay responsive while the chain was congested.
• Reading on-chain data directly was slow and expensive, so the trading screens needed a data path of their own.

02 What I did

• Designed and built the core exchange features: order-book trading, our own AMM pool program, and Jupiter-based swaps and limit orders.
• Set up our own RPC endpoint, tuned the polling interval for order books, and connected TradingView charts to a datafeed we built.
• Designed the AWS infrastructure (ECS, RDS, ElastiCache, MSK, WAF) as Pulumi code, organised into eight microservices.

03 Result

• Built order-book trading, swaps, liquidity pools, a launchpad, and staking for Solana mainnet.
• Designed the whole stack, from the exchange front end to on-chain programs and infrastructure.

01 Problem

• A booking goes through several stages and outside vendors before it is confirmed.
• Done synchronously, one slow stage makes the user wait, and a failure leaves the booking half-done.

02 What I did

• Accept the booking first, then run the remaining stages asynchronously with Spring application events.
• Keep each stage's state in Redis so retries do not process anything twice.

03 Result

• Users get an immediate response while confirmation happens in the background, and the booking system has run stably since.