Creator
Folarin Akinloye, AI Engineer and Creator of Agentling
I build agentic systems and AI-powered products, and I created Agentling, an open-source Python framework for building AI agents.
My work sits where agent architectures, AI infrastructure, and product engineering meet. I design and build systems that reason through a task, call tools, retrieve what they need, coordinate the steps of a workflow, and behave predictably once real people depend on them. Agentling is the part of that work I released as open source: the loop, memory, and event model I kept wanting and could not find small enough to read in one sitting.
What I work on
Agentic AI systems
I design agents and the workflows around them: tool-calling loops, multi-agent backends that route work by complexity and cost, and pipelines that carry a task through several steps without a person holding each one together. On the AI platform at Cuvama I built a tiered multi-agent backend in LangGraph that routes tasks across OpenAI, Anthropic, and Bedrock models by complexity, cost, and token budget. The interesting decisions are rarely about the model. They are about which tools an agent gets, how its subtasks are split and coordinated, and what happens when a step fails halfway through.
AI product engineering
A prototype only has to work once, in front of its author. A product has to work for people who did not build it, on inputs nobody predicted, inside an interface that stays honest about what the model is doing. I own that whole surface end to end: model and tool integration, backend services, the workflow design in between, and the interface on top. That has included streaming chat, live visualisation of tool calls and agent activity, progressive rendering over WebSockets, and plan-approval flows where an agent proposes a multi-step edit and a person reviews it, with versioning, before anything changes.
AI infrastructure and reliability
Retrieval, context management, evaluation, observability, and recovery are not finishing touches. They are what make a system usable at all. I have built version-aware retrieval with Agentic RAG on MongoDB Atlas Vector Search, replacing bulk context injection with typed tool calls, and I have wired LangSmith evaluation pipelines into GitHub Actions so that a regression in agent behaviour blocks a merge rather than reaching users. Reliability, predictable behaviour, and quality you can measure are the difference between a system that demos well and one a team will keep.
Working with startups
I work on practical AI problems in startup environments, where a small team has to turn a new capability into something useful without building more than the problem needs. That means working across product and engineering at once, making the architecture calls, and delivering the whole thing, from the data layer to the pixels. The judgement I bring is about what to build and what to leave out, not only how.
Why I built Agentling
Most agent frameworks hide the loop. When something goes wrong at three in the morning, that is exactly the part you need to read. I wanted a framework where the whole execution model fits in your head: one async generator drives every run, every step is a typed object, and every event the loop emits is one you can see. Agentling is that framework, built Python-first for asyncio, and kept small enough that the source is the documentation of last resort.
- Async, Python-first execution. The loop, the tools, and the model calls are all async. Tool calls within one step run concurrently by default, so an agent that needs three lookups does not wait three times.
- A ReAct-style loop with one code path. Blocking and streaming modes share the same generator, so what you observe in the stream is exactly what happened in a blocking run.
- Typed memory. A run is a list of typed steps, not a pile of message dictionaries. Steps render themselves into model messages and serialize to JSON, which is what makes persistence, replay, and resuming possible without extra machinery.
- Streaming events. A small set of typed events reports everything the loop does, which is what an interface needs to show progress honestly and what an operator needs to debug a run.
- Recoverable failures and resumable runs. A tool that raises becomes an observation the model can act on. Per-call timeouts, output truncation, and error redaction are built in. A run can be interrupted and resumed from the step where it paused.
- Provider abstraction. The built-in adapter speaks to any OpenAI-compatible endpoint, and the Model protocol is small enough to implement for a provider of your own.
- Runs without a key. The repository ships examples that run offline against a scripted model, so you can see failure recovery and memory persistence work before you configure a provider.
Source on GitHub, documentation, installation, examples, and the package on PyPI. MIT licensed, Python 3.11 or newer.
Engineering principles
None of these are original. They are the rules I keep coming back to when a system is on the line.
- Agents should be useful, not just impressive. Design around a real task and an outcome you can measure, not around the demo.
- Reliability is part of the architecture. Failures, retries, observability, and recovery are designed in at the start, not patched on after the first incident.
- Evaluation matters. Agent behaviour is tested systematically and regressions are caught in CI, not discovered in a demo that happened to go well.
- Abstractions should solve real problems. A framework earns its abstractions by removing work, and it must never hide the execution details you need when something breaks.
- AI belongs in products.The model, the tools, the interface, the infrastructure, and the user's workflow are one system, and they are designed together.
Selected AI engineering work
- Agentling. An async Python framework for tool-using agents with typed memory, streamed events, concurrent tool calls, recoverable failures, and resumable runs. The problem it addresses is execution you can read, replay, and trust.
- From Demo to Product. A written series on what it takes to turn an AI prototype into a product: architecture, unit economics, risk, quality ownership, and interface design. Selected pieces:
- The Reference Architecture for a Production AI App. Why the model call is a small part of a production AI app, and what the surrounding components have to do.
- Skills vs MCP vs Tools vs Subagents: Stop Conflating Them. Four different ways to extend an agent, what each one is for, and how they fit together.
- Agent Memory: Short-Term vs Long-Term, and How to Wire It Up. The two kinds of memory an agent needs and how to implement each without overbuilding.
- Designing UX for a Confidently-Wrong Intern. Interface design for AI features that can be wrong or slow, unlike conventional software.
- OpenFocus. A study companion built as a multi-agent app, with five agents that each teach in a different style. The problem is coordinating several specialised agents behind one conversation without the seams showing. Live app.
- finops-agent. A multi-agent personal finance app for budgeting. The problem is splitting a money question across agents that each own one job and getting one coherent answer back.
- adzuna-job-search-mcp. An MCP server that lets an agent search jobs, analyse salaries, and research employers across 12 countries through the Adzuna API. The problem is exposing an external dataset to agents as typed, bounded tools.
- uk-visa-sponsor-mcp. An MCP server that lets an agent check whether an employer is a licensed UK visa sponsor. The problem is turning a government register into a single reliable yes-or-no tool call.
- UK Visa Sponsor Search. A daily-updated, searchable list of UK visa sponsors sourced from gov.uk. The problem is making a large, awkward public dataset fast to search and keep current without manual work. Live app.
Professional background
I have been building software for nine years, the last two mostly on agent systems. Since 2024 I have been a Senior Product Engineer on the AI platform at Cuvama, where I own the frontend platform and the product's AI surface end to end. Before that I spent five years at lead level building real-time financial interfaces: crypto portfolio analytics and live equities trading, leading frontend teams of seven and five. The tools I reach for most are Python and TypeScript, LangGraph and LangSmith, MCP servers for giving agents access to external systems, retrieval over vector search, and evaluation pipelines that run in CI.
Contact and profiles
- Website: folarin.dev
- Writing: folarin.dev/blog
- GitHub: github.com/folathecoder
- LinkedIn: linkedin.com/in/akinloye-folarin
For security reports about Agentling, see the contributing page.
Short biography
Folarin Akinloye is an AI engineer who builds agentic systems and AI-powered products. He is the creator of Agentling, an open-source Python framework for building AI agents. His work focuses on agent architectures, AI product engineering, and the infrastructure needed to build reliable AI systems.