What does the setup actually do?
Our setup helps us move from a business request to a reviewable result: understand the job, retrieve relevant context, prepare or build the work, inspect it and record what happened. We keep instructions and project knowledge alongside the work so that a new session can recover decisions without asking the owner to repeat them.
This is an agency operating setup, not a product bundle we think every founder should copy. A team that needs better first drafts may need one approved assistant and a shared template. We need additional machinery because our work crosses software, content, communications and business records. Every extra connection creates upkeep.
Our practical test is simple: can another person see the original request, the source evidence, the permission to act and the final result? A confident AI message saying that a job is finished does not answer that question. This account reflects our editorial review on 12 October 2026; it does not claim every tool is continuously available.
Which tools earn a place?
| Tool or layer | Why we use it | Tradeoff to accept |
|---|---|---|
| Claude Code | Work across project files, commands and repeatable instructions. | Needs clear scope and review of the actual result. |
| Codex | Build, inspect and test changes in a project workspace. | A passing command does not establish business correctness. |
| Kimi Code | An additional coding route for assigned implementation work. | Its access and limits need separate verification. |
| Composio | Connect authorized app accounts to scoped business actions. | Account selection, permissions and connection health remain our responsibility. |
| Supabase | Keep application records and file storage where a project needs them. | Access rules, data structure and retention still need design. |
| Vercel | Host web projects and create deployments we can inspect. | Usage, environment settings and release coordination need an owner. |
The product capabilities are documented by Anthropic, OpenAI, Kimi, Composio, Supabase and Vercel. The reasons and tradeoffs in the table are our own operating judgments.
Why use several assistants?
We use Claude Code, Codex and Kimi as working environments that can act on files and tools. The model is one part of the arrangement. Instructions, access, source material and the ability to verify an output matter just as much. We assign bounded work and judge the artifact it produces, not the name attached to it.
The upside is choice and a second way to examine a difficult task. The downside is coordination: different sessions can hold different context, overlap on files or report different conclusions. We do not treat several agreeing answers as independent evidence if they all started from the same mistaken assumption.
For a small team, our recommendation is to learn one approved assistant well before adding another. Introduce a second only for a defined reason, such as reviewing important work or handling a task your first tool cannot complete. Keep the same acceptance criteria when switching. A fallback that quietly changes the expected output or privacy terms is a different workflow.
How do apps become a usable workflow?
We use Composio for managed app connections where the integration fits. Its documentation describes connected accounts and authentication configurations. That connection layer lets an assistant reach an authorized service; it does not decide whether contacting a customer or changing a business record is appropriate. Composio authentication documentation.
Our operating process checks the specific account, the specific matter and the allowed action. Reading a record, preparing a draft, updating a record and sending a message are separate permissions. We keep sensitive access material out of public work and ordinary project content.
Supabase supplies database, authentication and storage capabilities; Vercel supplies the deployment environment for web projects. In our work these support durable records and reviewable web surfaces. They are not replacements for the business owner deciding which record is authoritative. Supabase documentation; Vercel deployment documentation.
For your business, start by naming the system that owns each outcome. If a booking belongs in your booking system, an AI conversation confirming it is not enough. The final check belongs at the destination, where your team will rely on it tomorrow.
What happens between a request and done?
- Recover context. Read the current brief, previous decisions and the relevant source records.
- Define the result. State what changes, who it serves and what would make it unacceptable.
- Prepare the work. Keep scope bounded and preserve a reviewable history.
- Verify. Check content, run relevant software checks, inspect the rendered interface and confirm persisted results.
- Close the loop. Record the result, evidence, limitations and remaining owner.
For visual work, we inspect real browser renders at mobile and desktop sizes. A build can pass while a title is clipped or a form is unusable. For a workflow that saves something, we check the saved record. For communication, a prepared draft and a successful send are different states.
A person provides the authority for an external send, through an explicit instruction or an applicable authorization for that workflow. We retain that authorization for the approved scope rather than repeatedly asking the same question. Changed recipients, different content or a new matter need to be evaluated against that scope. The assistant still needs evidence of the send outcome.
What have we stopped using, and why?
Our internal records document retiring the Unipile intake route after it returned empty results in circumstances where the result could not be trusted. That is a finding about our integration at that time, not a claim that the vendor cannot serve another business. The lesson was to distinguish an empty inbox from a failed collection.
We stopped repeated scheduled notifications that kept resurfacing the same items without useful progress. More reminders did not improve ownership. The pattern worth copying is to retire an automation when its output stops helping someone make a decision, rather than preserving it because it took effort to build.
These are documented DLVX decisions, reviewed on 12 October 2026. We have not measured a universal cost or productivity improvement from those changes and do not attach one to them.
What should a smaller business borrow?
Borrow the discipline before the infrastructure. Choose a repeated handoff, give one person ownership, collect a small permissioned test set and specify the output. Keep a manual fallback. Add a connection only when copying between systems is itself the problem.
- Good first scope: turn an enquiry into a sourced draft and a next action.
- Good first review: compare the draft with the original request and current business rules.
- Good first measure: accepted work after correction time, not messages generated.
- Good stop rule: missing evidence, wrong identity or an action outside permission.
Common mistakes are buying every assistant at once, giving broad access before testing, letting old notes stand in for current records and declaring success from an automation log alone. Our own setup has needed corrections in all of these areas. Written rules also need checks that actually run; the existence of a rule is not proof it is enforced.
Next step: write down one task, its source system, the reviewer and the evidence that would prove completion. Use that brief to decide whether an ordinary assistant, an existing app feature or a custom connection is justified.
How we checked this account
DLVX editorial review, 12 October 2026. We checked our operating manuals, capability inventory, documented retirement decisions and project handoff. Public vendor sources below establish product capabilities; the descriptions of our own choices come from that internal review. Private records, credentials, customer information and infrastructure addresses are deliberately excluded.
Availability changes between interactive sessions and scheduled workers. We therefore describe the tools we use without presenting an old service list as a live uptime report. We found no reliable basis here for a claim that we use Superhuman, so it is not included as part of our setup.
Sources and review date
Reviewed 12 October 2026. Prices and plans are as of October 2026. DLVX recommendations are editorial judgements, not a vendor ranking or a promise of results. Recheck the linked terms before buying or connecting business data.
- Claude Code overviewChecked 2026-10-12. Reads files, edits code and runs commands.
- Codex CLIChecked 2026-10-12. Inspects, edits and runs code in a terminal workspace.
- Kimi Code overviewChecked 2026-10-12. Terminal coding environment with file and command capabilities.
- Composio authenticationChecked 2026-10-12. Connected accounts and authentication configurations.
- Supabase documentationChecked 2026-10-12. Database, authentication and file storage capabilities.
- Vercel deploymentsChecked 2026-10-12. Web deployment workflows.
- DLVX editorial review, 12 October 2026Checked 2026-10-12. Internal tool use, send authorization, review habits and retirement decisions.
Want to apply this to your team? Get a free AI plan.