Career & Activities
Kota Kawagoe
Software Engineer
A software engineer working to bring autonomous AI agents into real deployment — from hackathon-speed prototypes to services that stay up.
Looking for: roles in AI application engineering or backend systems.
32.6%
WebArena Shopping task success rate (Browser-Agent)
N=187 / max steps 40 / retries 4 / identical prompt
1.7×
Task success rate after optimising long/short-term memory
Multi-agent orchestration system, presented at NCSP’26
70/1800
Matsuo Lab LLM course competition — top 4%
LoRA SFT + DPO fine-tuning, 2024–2025
2services
Personally built and still running in production
chatcore-ai.com · fs-qr.net
Summary
AboutMy strength is the combination of AI, design, and English. Those three let me take a technology and turn it into something people can actually use — and then explain it, in either language, to the people who need to understand it.
Beyond engineering
My value isn’t only in writing code — it’s in thinking through the business behind it: where real demand exists, what it costs to run and sustain a service, and how to shape that into something viable. That’s why I’m suited to taking a new venture from zero to one, owning the full range from prototyping at hackathon speed to steady production operation. The services still running today are the evidence.
What I have actually built
I built a multi-agent orchestration system that integrates a browser agent, an IoT agent and others, so that tasks don’t stop at the browser but reach back into the physical world through hardware. I optimised its long- and short-term memory handling and raised the task success rate 1.7×, then presented the work in an English oral session at NCSP’26 in Honolulu.
Now, and where I am headed
DirectionIn the master’s programme I am building a general-purpose agent platform on which four kinds of AI resource — Memory, Skill, Tool and Agent — can be registered, searched, selected and executed through one common format.
The platform manages resources of quite different natures under one scheme, picks the combination a given task needs, and checks safety and permissions before it runs anything. Task planning, state management, human approval, failure recovery and audit logging are consolidated into the same layer — the goal being an “OS kernel for AI agents” that is tied to no particular LLM and no particular use case.
Alongside it I keep building web applications on a range of LLMs and researching agent architecture — RAG-based retrieval, ReAct implementations, personalisation through memory updates. The browser-operation agents, the IoT agents and the orchestration layer that ties them together all sit on the same line of work.
What I am aiming at through all of this is to get AI agents actually deployed in society — to give people back their spare hours, and to make a society where communication between people is more active. That is the reason I care as much about a service staying up as about building it in the first place.
How I got here
Timeline- 2021Apr Entered Kanagawa Institute of Technology, Faculty of Information Technology.
- 2023Jun Took a one-year leave of absence to study abroad at the University of North Alabama. Named to the Dean’s List and placed 1st of 30 in the AI course final project.
- 2024May Returned from the exchange program and resumed study.
- 2024–2025 Took part in Matsuo Lab programs. Placed in the top 4% (70 / 1,800) of the LLM course competition.
- 2025Apr Started joint research with Manaable Inc. as project lead on RAG system optimization.
- 2025Sep Presented the joint research at FIT 2025. A patent was co-filed from the findings.
- 2026Mar Gave an English oral presentation at NCSP’26 in Honolulu, and graduated.
- 2026Apr Entered the M.S. program in Cyber Informatics at Keio University Graduate School of Media and Governance, and began research on a general-purpose AI agent platform.
Services running today
LiveChatCore-AI
In operation
AI chat with email authentication, plus a place to share and search prompts between users. Built on FastAPI and Next.js, deployed with Blue-Green releases behind nginx.
chatcore-ai.comFS-QR
In operation
Self-hosted file and note sharing: instant transfer by QR code, password-protected group rooms, and notes that sync in real time over WebSocket.
fs-qr.netExperience
WorkManaable Inc.
Joint Researcher / Project Lead
- Lead researcher for RAG system optimization. The team split the work into three steps — masking personally identifiable information in Q&A data, validating consecutive masked records by comparing multiple LLMs, and evaluating storage formats for RAG — with one member owning each. As project lead I applied my prior RAG chat development experience to support each member’s implementation, design, and validation direction, version-controlled code and experiment records on GitHub, reviewed every change, and kept the team aligned on one implementation direction.
- Patent Co-filed a patent based on the findings of this research (pending).
- Paper Presented the results at FIT 2025 (24th Forum on Information Technology), demonstrating measurable gains in answer reliability. → Paper (PDF) / Session program
Manaable Inc.
Software Engineering Intern
- Joined as an intern after the joint research ended, to bring its findings into a real product: designed and built an in-house AI agent system for the customer support team on AWS.
- Converted the operations manuals accumulated in Jira into structured Markdown, then built a hybrid RAG pipeline (BM25 + vector search) on gpt-5.1-mini, iterating on prompt design so the chat UI could answer questions in natural language.
- Extended it past simple RAG chat into a full support agent: automatic Jira ticket creation via the Jira API, and auto-drafted customer-facing emails alongside each RAG answer.
- Ran daily discussions with the support team while they actually used it, iterating from requirements through response quality.
- Developed each feature on a dedicated
feature/*orfix/*branch and merged through Pull Requests with clear descriptions; also acted as reviewer on teammates’ PRs to keep code quality and direction consistent.
Working on a team
CollaborationI support the direction rather than take the work away
On the joint research the work was split into three steps with one member owning each. As project lead I didn’t take those steps over — I applied my earlier RAG experience to each member’s implementation, design, and validation direction, and kept the three tracks pointed the same way.
Decisions and experiments stay in the repository
I version-controlled not only the code but the experiment records on GitHub, and reviewed each member’s changes. Keeping what was tried and why in one place is what let three people’s results be compared at all.
I review as well as get reviewed
During the internship I developed each feature on a feature/* or fix/* branch and merged through Pull Requests with clear descriptions. I also acted as reviewer on teammates’ PRs, leaving structured feedback to keep code quality and direction consistent.
I sit with the people who will use it
For the support agent I ran daily discussions with the customer support team while they actually used it, iterating from requirements through response quality. Reading the gap between what was asked for and what was actually needed is only possible at that distance.
Key projects
BuildBrowser-Agent
LLM-powered browser automation with a web UI
Dec 2025 – Mar 2026Solo
An LLM-driven browser automation agent that wraps browser_use with a FastAPI backend and a noVNC web interface, supporting natural-language control and WebArena benchmarking. WebArena Shopping task success rate: 32.6% (N=187, max steps 40, retries 4, identical prompt setting).
StackPython · FastAPI · Docker · browser_use · noVNC · Gemini / OpenAI / Anthropic
ChatCore-AI
AI chat and prompt sharing — running in production
Feb 2025 – ongoingSolo
An AI chat application built with FastAPI and Next.js. Email authentication, Groq/Gemini API integration, and prompt sharing and search between users. Deployed with Blue-Green releases behind nginx.
StackPython (FastAPI) · Next.js · PostgreSQL · Redis · Docker · Groq / Gemini API
Symphony Agent Conductor
Autonomous orchestration platform
Oct 2025 – Apr 2026Solo
A central orchestrator built on LangGraph that coordinates specialized agents for browser operation, IoT control, and retrieval, connecting digital tasks with physical device control in one flow.
StackPython · Flask · LangGraph · browser-use · IoT (Jetson / Raspberry Pi) · OpenAI / Gemini
Other projects
-
Chat-driven device control with a dashboard and camera snapshots, supporting Jetson, Raspberry Pi, and Pico W. Runs a local LLM on an NVIDIA Jetson Orin Nano for low-latency, offline-capable intelligence at the physical layer.
-
A chat-first assistant for routines and tasks with a timeline view, switchable across OpenAI, Gemini, and Anthropic models.
-
A multi-domain lifestyle RAG agent with MCP support, a web chat UI, and conversation analysis for proactive assistance.
-
An interactive locked-room mystery where Gemini 3 acts as game master, generating a fresh case each time and answering player questions. Built with Nano Banana at the Gemini 3 Tokyo Hackathon 2026.
-
A self-hosted file and note sharing tool with QR-based instant transfer, password-protected group rooms, and real-time shared notes.
Periods are taken from repository creation to last push on GitHub, so they may run slightly later than when work actually started.
Problems I got stuck on
Debug logSeven problems that actually cost me time, with what I tried and what finally worked. Several are failures of my own first instinct — those are the ones I learned the most from.
01 Date-calculation hallucinations in an LLM agent
What went wrong
The agent kept getting dates and weekdays wrong. “Put lunch on next Friday” would land on some other day. Because an LLM is a probabilistic text generator, even a deterministic calculation like “how many days until next Friday” shifts with small changes in context. Prompt tuning alone clearly hit a ceiling.
How I solved it
I stopped having the LLM calculate dates and split the responsibilities instead: the LLM only interprets the user’s intent (which weekday “next Friday” refers to), while all actual date arithmetic goes to dedicated deterministic functions that always return the right answer. Date handling became stable regardless of model. Validated with a benchmark of 9 models across 10 tasks, where a mid-tier model beat several frontier models — evidence that reliability comes from design, not from model capability alone.
02 Production-only nginx proxy bugs — SSE buffering and WebSocket upgrade
What went wrong
Two separate production failures with the same root shape: nginx sits between client and server in production but is bypassed in local development, so neither bug was visible until deploy. In ChatCore-AI, token-by-token SSE streaming worked locally but arrived as one block in production. In FS-QR, real-time WebSocket text sync worked locally but failed to connect in production.
How I solved it
SSE: nginx’s default response buffering was swallowing the stream — fixed with proxy_buffering off and X-Accel-Buffering: no. WebSocket: nginx defaults to HTTP/1.0 and drops the Upgrade header the handshake needs — fixed with a location block setting proxy_http_version 1.1, the Upgrade / Connection headers, and longer timeouts, plus Redis Pub/Sub to broadcast across instances. Hitting the same class of bug twice made the habit stick: validate streaming and persistent connections behind a production-equivalent nginx, not just locally.
03 OSS internal state corruption — residual state polluting the next task
What went wrong
I reused browser sessions across tasks for efficiency, but state left inside the library after one task interfered with the next. Ending the session cleanly shut it down entirely; leaving it alone let state accumulate until a crash. Neither option worked.
How I solved it
The library exposed no public API for resetting internal state, so I read its source directly to understand the internals and wrote a cleanup routine that runs after each task. Since the internals differ between versions, I added version-aware fallback logic so cleanup works on any installed version. It reinforced that when you hit the edge of a public API, read the source rather than relying on the docs.
04 LLM output contradicting its own generated data — a dual-LLM verification loop
What went wrong
Gemini generated the case data (characters, alibis, evidence, timeline) and then acted as game master answering player questions — but it contradicted its own case. It would reveal the culprit’s alibi accurately, or have a character defined as a liar answer honestly, making the game unsolvable.
How I solved it
Within the seven-hour limit I built a two-stage response pipeline: generate the answer, then pass it through a separate LLM call that cross-checks it against the original case data and corrects contradictions before delivery. I also added automatic retries that reject structurally malformed case generations. The insight: an LLM cannot reliably self-censor against structured data it generated earlier in the same context — verification has to live outside the generation call.
05 A shell script’s execute bit breaking the GitHub Actions deploy
What went wrong
The automated deploy pipeline kept failing at the step invoking ./deploy.sh. Running bash deploy.sh manually on the server worked fine, so local testing never caught it. The runner exited with “Permission denied” while the file existed and its contents were correct.
How I solved it
The execute bit (+x) had never been recorded in git’s index. Running chmod +x locally changes the filesystem but git only tracks it if you stage it with git update-index --chmod=+x deploy.sh. After committing that, the runner inherited the bit and the deploy succeeded. The gap between filesystem permissions and git-tracked permissions is easy to miss precisely because bash script.sh never needs the execute bit — it only surfaces when a runner executes the file directly.
06 Face-recognition accuracy — the bottleneck was the data, not model capacity
What went wrong
I built a face-recognition login system with ResNet and TensorFlow, but accuracy fell short. My first instinct was that the model lacked representational power, so I added hidden layers to increase capacity. Accuracy barely moved — and adding capacity against a limited dataset risks overfitting, pushing in exactly the wrong direction.
How I solved it
I reframed the plateau as insufficient volume and diversity of training data rather than insufficient expressiveness. Rotating the face images and adjusting brightness introduced variation in camera angle and lighting into the training set; the model became robust to those variations and accuracy improved. The lesson: don’t equate “low accuracy” with “make the model bigger” — first determine whether the bottleneck is on the model side or the data side.
07 Blue-Green deployment timing — momentary 500s during the switch
What went wrong
I set up Blue-Green deployment with GitHub Actions and nginx for zero-downtime updates, but users occasionally hit a 500 for a split second during the switch. The script was pointing nginx at the new Green environment before the application process inside the container was ready to accept connections — even though Docker already reported the container as running.
How I solved it
I added an application-level health check to the deploy flow: instead of just waiting for the container, the script polls the new container’s /health endpoint and only updates and reloads nginx once it actually returns 200 OK. Traffic now reaches only fully initialised instances and the errors disappeared. “Container ready” is not “application ready” — CI/CD pipelines need health validation at the application layer.
Education
SchoolKeio University Graduate School of Media and Governance
M.S. in Cyber Informatics, Graduate School of Media and Governance
Kanagawa Institute of Technology
B.S. in Information Network and Communication, Faculty of Information Technology
- Includes a one-year leave of absence.
- Graduation research: English paper (PDF) · Japanese paper (PDF) · Research page
University of North Alabama
International Exchange Program
- Honors Dean’s List, Fall 2023 (GPA 3.75 / 4.0).
- 1st / 30 Ranked first in the Artificial Intelligence course final project — a face-recognition login system built with OpenCV and TensorFlow.
- Relevant coursework: Artificial Intelligence, Intro to HCI/UX, Design I & II, Applied Computer Science.
Activities
OutsideMatsuo Lab Programs & Competitions
LLM course, competitions, and specialized programs
- Top 4% LLM course final project and competition: built fine-tuned models with LoRA SFT and DPO, placing 70th of 1,800. Model: Llama-3.1-8B-Instruct-Freedom_v3
- LLM Competition 2025: owned training-data creation for the team, building and publishing a high-difficulty synthetic dataset for mathematical reasoning. → difficult_math_deepseek_llama
- Specialized courses taken: AI Management (joint with PwC), LLM, GCI (data science fundamentals), Deep Learning, Deep Generative Models.
NCSP’26
2026 RISP International Workshop on Nonlinear Circuits, Communications and Systems
- English oral Presented research on an AI multi-agent orchestration system in an English oral session.
- The system integrates five specialized agents: RAG, web operation, IoT, scheduler, and orchestrator.
- → NCSP-Presentation-EN.pdf
- → NCSP’26 official program (NCSP26_Sessions.pdf) / NCSP’26 official site
Gemini 3 Tokyo Hackathon 2026
Built and shipped inside a 7-hour limit
- Completed a mystery game powered by Gemini and Nano Banana within the seven-hour limit. → Gemini3-Hackathon-Mystery-Game
Skills
Stack- Programming Languages
- PythonTypeScriptSQL
- Web / Application
- FastAPIReactNext.jsTailwind CSSPostgreSQLRedis
- AI / LLM Engineering
- RAGMulti-Agent SystemsLangChainLangGraphbrowser-use
- Infrastructure
- DockerAWS (EC2, VPC, Systems Manager)LinuxNginxGitGitHub Actionspytest
- IoT / Hardware
- NVIDIA Jetson Orin NanoRaspberry Pi 4Pico W
- AI Tools
- CodexClaude CodeNotebookLMAntigravityGeminiChatGPTClaude
How I actually use AI tools
Listing the product names says nothing on its own, so here is which phase each one covers. Design decisions and review stay with me throughout — the tools change how fast I move, not who is accountable for the result.
- Research & learning NotebookLM
- Ingest papers, technical docs, and lecture material to produce summaries and structured notes — so I can get a footing in an unfamiliar domain before writing any code.
- Documents & presentations Claude
- Draft and iteratively refine slides, documents, and technical reports. I use it as a writing partner for structure and clarity, not as a source of content.
- Coding Codex, Claude Code, Antigravity
- Scaffold features, debug, write tests, and refactor. Agentic tools handle changes spanning multiple files across a full-stack project — but the design decisions and the review stay mine.
- Ideation & problem solving Gemini, ChatGPT, Claude
- Brainstorm architecture decisions, explore design trade-offs, and pressure-test a technical approach by talking it through before committing to it.
- Japanese
- Native
- English
- Professional proficiency TOEIC 715 · one academic year studying in the US · conference talk delivered in English