We design, build and ship AI agents from Hanoi. That means systems that take an instruction, decide what steps to run, call your tools and data, and produce a result a person can act on or check.
This page is written for someone who has already decided an agent is worth building. If you are still at the stage of working out what to delegate, our post on outsourcing AI agent development covers that, and our buyer's guide to AI development companies in Vietnam covers how to check any vendor, including us.
Demand here is real and recent. Stanford's 2025 AI Index reports that 78% of organizations said they used AI in 2024, up from 55% a year earlier, with $33.9 billion of global private investment going into generative AI in 2024 alone. A lot of that money is now being spent on the unglamorous part: making these systems work inside real business processes.
Workflow or agent: the distinction that decides your budget
Before anything else, we work out whether you need an agent at all.
A workflow follows a path you defined. Read the email, extract four fields, look up the customer, write a row, send a reply from a template. It is predictable, cheap to test, and when it breaks you know where. Most "AI automation" requests turn out to be workflows with one model call inside them.
An agent decides the path itself. Given a goal, it picks which tools to call and in what order, reacts to what it finds, and stops when the goal is met or it gives up. That flexibility is the point, and it is also the cost: you cannot enumerate every path, so you have to invest in evaluation, guardrails and logging instead of ordinary test cases.
An agent costs more to build and considerably more to verify. When the work really is a workflow, we build a workflow and say so.
What we build
Four shapes cover most of what clients ask us for, and we have shipped all four.
Customer-facing assistants that resolve routine requests and hand the rest to a person with context attached. We built the customer support chatbot for StarHub, a telecommunications provider in Singapore, to absorb the repetitive share of thousands of daily inquiries and to collect the customer details an agent would otherwise have to ask for again.
Internal assistants that read your documents and answer questions over them, with the source shown so the reader can verify it. The pet healthcare app we built with Dify is the consumer version of this pattern. Health and location data put it under GDPR and CCPA, so translation data and health records were processed accordingly and anonymized. Its published six-month figures are 95% translation accuracy, a 32% retention improvement against the previous benchmark, more than 20,000 monthly active users across eight countries and a 4.8 out of 5 App Store rating.
Agents that produce engineering artifacts. Our own AI test case generation platform combines an ISTQB-compliant knowledge base with a fine tuned language model to generate reusable, standards-aligned test cases. We run it on our own projects, which means we feel its failure modes before a client does.
Agents embedded in a domain system, where the model is one component inside software that also has a database, a UI and a compliance story. The agritech system with generative AI is that kind of build.
How we run an agent project
Five stages. Each ends with something you can hold.
Scoping comes first and is mostly about agreeing what a correct output is. We go through real examples of the task with the people who do it today, write down what good looks like, and decide where the agent must stop and ask a human. This is where we tell you if you are describing a workflow.
Next we build the evaluation set. A collection of real inputs with known-correct outputs, large enough to be meaningful and specific to your business. It is slow, unglamorous work and it is the single most useful thing we hand over, because it is what lets you change models later and know within an afternoon whether the change helped.
Then the build itself: retrieval over your content, tool and API integration, the agent loop, and the interface where a person reviews or overrides what it did.
Guardrails come with the build, not after it. A confidence threshold below which the agent says it cannot answer. Routing to a person when that happens. Sources displayed next to generated answers. Logs that let you reconstruct why a given output appeared on a given day. Limits on what the agent is allowed to do without approval.
Deployment and handover put it into your environment, with monitoring for quality and cost, and a document describing how to run it. If you want us to keep operating it, we can, through a standing team in our offshore development center. If you want to take it in house, nothing is locked.
How we think about risk
Guardrails are easier to agree on when both sides use the same vocabulary. We work from the NIST AI Risk Management Framework, whose core is organized around four functions: govern, map, measure and manage. It is a voluntary framework rather than a standard anyone certifies against, and we use it as a checklist rather than a badge.
In practice the four map onto our five stages fairly directly.
Govern is the part most agent projects skip. It means deciding, before the build, who is accountable for the agent's behavior on your side and what it is not allowed to do without a human. We put those decisions in writing during scoping.
Map means understanding where the agent sits in a real process and what happens downstream of a bad output. An agent that drafts a reply for a person to approve carries a different risk profile from one that sends the reply itself, even when the model is identical.
Measure is the evaluation set. Without a measurement you have opinions about quality, and opinions do not survive contact with a board meeting.
Manage is what happens after launch: monitoring, periodic re-evaluation against the same test set, and a documented way to roll back a prompt change that made things worse.
None of this makes an agent safe in the abstract. It makes the specific risks visible early enough to design around them, which is the part that affects your schedule.
When an agent is the wrong answer
We would rather tell you now than six weeks in.
When the task has one correct answer and a fixed procedure, a workflow or plain code will be cheaper, faster and more reliable.
When nobody can say what a correct output looks like, no amount of engineering will fix it. The project needs a decision first, not a model.
When the underlying data is missing or inconsistent, the agent will reliably produce confident nonsense. Fix the data, then build.
When a wrong answer is unacceptable and cannot be caught by a reviewer, the honest answer is that current models are not suited to the task on their own.
What you own at the end
The source code. The prompts. Any fine tuned weights and the data behind them. The evaluation set. The documentation. We set this out in the agreement rather than leaving it to be discovered later, because the prompt library and the evaluation set are usually worth more than the code around them.
Working hours
Our engineers are in Hanoi, GMT+7, with no daylight saving. Singapore is an hour ahead and Sydney three or four depending on the season, which gives those teams a shared working day with us. From the US and Europe the overlap is narrower, so we run agent projects with written decisions and one reliable daily call.
Agent work in particular needs your judgment early and often. Somebody on your side has to look at real outputs and say whether they are acceptable. We plan that review into the schedule rather than hoping for it.
Start a conversation
Tell us the task you want an agent to do, what data it would need, and who on your side decides whether an answer is good. We will tell you whether it is an agent or a workflow, what we would need before estimating anything, and how we would measure it.
Our wider AI development service covers model integration and applied machine learning as well, if the project turns out to be one of those.
