Build
Connect to tools you already use
Tobiloba Odejinmi · 23 Jun 2026 · 6 min · 1,005 words
Direct answer
Connect the AI employee to the tools you already use so the work shows up where people already look. Help desk, CRM, inbox, calendar, the HR pile, the sheet that is secretly the ledger. Days 4 to 6 of the week are this job. If the build needs a new login to be useful, you are not shipping an employee. You are shipping a tour.
- Time-to-first-useful-action in an existing tool is the product.
- Ugly APIs are still better than a new tab nobody opens.
- A knowledge store is your documents, not a second wiki.
- If setup needs a project plan, the first process is too wide.
Why should an AI employee use tools you already have?
Because that is where the work already dies or gets done. A new interface is a new habit. Most teams do not have spare habit. If the employee drafts a reply, it should draft it in the help desk. If it screens a CV, the shortlist should appear where hiring already lives. If it writes a follow-up, the note should sit on the lead.
I learned this the unromantic way at Zeeh. Banks used us when they could plug in before lunch. Clever surfaces waited for a champion who never got budget. An AI employee is the same product problem. If your team needs a workshop to find the output, you built a demo.
Which connections are worth doing in week one?
The trigger and the write-back. That is the minimum live employee. Read the ticket, write the reply or the tag. Read the CV, write the shortlist fields. Read the lead, write the first note and a flag. Fancy side lookups can wait if the core path works. They cannot wait if the human cannot finish a case without them. The map tells you which is which.
Permissions belong in week one too. A connection that only works on my laptop is not a connection. Days 4 to 6 include the service account, the scopes, and the person who can approve them. If that person is on leave, the sprint waits. I will not paper over access with a personal token.
What do you do when the API is ugly?
You use it anyway, and you hide the ugliness behind a small, boring layer. Pagination, odd status codes, fields that mean different things on Tuesdays. That layer is for the employee and for the person who will debug it at 2am. It is not a new product. It is how you stop the model from seeing raw chaos and inventing a field.
If the vendor API cannot do the one action the process needs, we say so on day 2, not day 6. There is always a temptation to 'just have the model email someone instead.' That is how you create a shadow process. I would rather change the first process than teach the company a new unofficial channel.
Do you need a new knowledge base?
Only when the answers live in documents the tools do not expose. Policy PDFs. Internal how-tos. The refund exception list that is actually a Notion page with no owner. In the $7,500 week I will stand up a store for that if the work needs it. The store is for retrieval, not for your team to start a second documentation culture.
If the knowledge is already in the help desk macros or the CRM fields, we start there. Copying those into a new store so a vendor can sell you 'AI search' is a new religion. I am not here to convert you.
How do you keep logins from multiplying?
One service identity for the employee, listed in the handover, with an owner. People should not sign into a new app to supervise it. They should see its work in the queue they already run, and they should open the monitor when something looks off. That is two places, and the second is optional on a quiet day.
I treat extra logins as a product defect. Same as an API that needs a three-week workshop. The $5,000 workflow and the $7,500 week are priced for a connection job, not a procurement job. If we need legal to approve a new platform, we are in a different conversation, and I will say that before we pretend it is a seven-day build.
What is the before-lunch test?
Can a person who was not in the build open a real item, see what the employee did, and finish or escalate without a tour? Before lunch. If the answer is no, the connections are not done. The test is rude on purpose. It is the same test I used for banking APIs: if another team cannot call you, you still have work to do.
This is also why I do not start the week by picking a stack. TypeScript, Node, and Postgres are what I like. Your help desk is what your team likes. The employee lives at the join. Days 4 to 6 are successful when the join is boring. Boring is the point.
Questions people ask
Do we have to switch tools?
No. I plug into what you already use. The week is for taking work off people, not migrating the company.
What if our tools have no API?
Then we look at exports, inbound email, and the official automation the vendor already sold you. If none of that can start or finish a case, we pick a different first process.
Will you build a custom dashboard?
Not as the workplace. Monitoring can be a small view. The work itself should land in the queue you already run.
How many tools can one workflow touch?
As many as the human already touches for that process. Not as many as IT would like to consolidate. The map decides, not a platform diagram.
Is a new knowledge base required?
Only if the work needs documents the tools do not already hold. Even then it is a store behind the employee, not a place your team must go to live.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
