Software studio
Medellín, Colombia
AI systems, automation, integrations, and the software around them. We take them all the way into production — where they run unattended, and leave a trace when something breaks.
| node | status |
|---|---|
| whatsapp.trigger | ok |
| audio.download | ok |
| transcribe · whisper | ok |
| normalize | ok |
| fields_mapping | ok |
| agent.plan | ok |
| tool · check_availability | ok |
| tool · get_booking | ok |
| whatsapp.reply | ok |
node names and order read from the live workflow
Most projects touch at least three. An agent is only useful once it can reach a real calendar; an integration is only finished once someone can see what it did. We scope the work by the outcome, not by the category it belongs to.
Agents that use tools, hold context, and act on systems that matter — not a chat window bolted onto a FAQ. We decide what the model is allowed to do, what it has to ask about, and what happens on the days it gets something wrong.
The connective work between systems that were never designed to talk to each other. Triggers, retries, and the unglamorous error handling that decides whether an automation survives contact with real traffic.
Applications, dashboards, and the interfaces around a system — the place people go when they need to see what the automation actually did.
APIs, deployment, isolation, monitoring. Going live is a milestone, not the finish line — most of the value shows up in the months afterwards.
Not concepts. Both of these are deployed, and both handle traffic we did not schedule.
A booking system that starts with a voice note.
Someone sends a WhatsApp message — often audio, often at an hour when nobody is at a desk. The system transcribes it, works out what was actually being asked, checks the calendar, books the slot, and replies. No form, no callback, no queue.
One environment, many clients, no shared blast radius.
Each client’s workflows, credentials and data sit behind their own walls, so a change made for one can never reach another. Onboarding a client is a provisioning step rather than a rebuild, which is the difference between running a platform and maintaining a pile of one-offs.
These are not preferences. Each one is a decision that has already been made in the systems above, and each one costs something up front to hold.
A workflow running on somebody’s laptop is a prototype. We hand over systems that are deployed, credentialed and monitored — and until that is true, the work is not finished.
Most automation dies at the integration boundary, not at the idea. We build into the tools a business already runs on rather than asking a team to migrate to something new to make our job easier.
Every client gets their own environment. Your credentials, your data, your failure domain. A problem in one place should not be able to travel to another, and that has to be designed in rather than promised.
Things break. The only question that matters is how quickly you can see why. Runs are logged, failures are visible, and the path through the system stays legible after the fact.
Not a certification wall. This is what is in production right now — if something is not on this list, we will say so rather than learn it on your budget.
Tell us what the system needs to do and what currently happens instead. If we are the right studio for it we will say so, and if we are not we will usually know who is.
Tell us what the system needs to do. We reply to everything.
Atomic is led by Daniel Ramirez in Medellín, Colombia. More about Daniel Ramirez.