How this shortlist differs from a general AI company list
This guide is for a buyer whose software needs to carry work across business tools: read a request, retrieve permitted context, prepare an action and hand it to the right person or system. It focuses on integration and operating responsibility. Our broader company shortlist covers general AI development; this article asks what an agent project should require from a development partner.
We selected four companies with public AI, automation or related implementation offerings relevant to that conversation. Their official pages were reviewed on 22 October 2026. Kooya is first because we publish this guide and prefer our integrated product, design and engineering approach. We did not benchmark the companies, inspect their private deployments or verify current availability. The order is not proof that any team outperforms another.
The profiles below separate what each company publicly describes from our suggested questions. A broad AI services page is a reason to discuss a project, not evidence that every connector, approval mechanism or support arrangement is already available.
1. Kooya: start with the operating workflow
Kooya describes a Philippine-based studio combining product, design, AI and engineering, with Manila as its home base. Its public site includes agentic operations among its capability areas.[1][2]
Our proposed starting point is a bounded workflow brief: identify the person doing the work, the systems involved, the decision to support and the point where approval is required. For example, an agent might assemble a service-request summary and draft a ticket update while leaving a supervisor responsible for sending it. This is an illustrative brief, not a claim about a named client deployment.
Ask Kooya to demonstrate a working slice against permitted test data and explain every integration boundary. Our own proposal should be judged on the same evidence as the alternatives. Confirm who maintains credentials, investigates a failed run and approves changes to what the agent may do.
- Best starting conversation: one workflow spanning product decisions, user interaction and AI integration.
- Proof to request: a trace from source request through proposed action and approval.
- Contract question: who owns the deployed configuration, integrations and support responsibilities?
2. Symph: agents in existing business tools
Symph explicitly describes building agents and automations on customers’ CRM, ERP, spreadsheets and internal tools. Its site also describes taking AI-built prototypes into production through security review, integration, hosting, monitoring and handover. These are the company’s published service statements.[3]
Kooya’s reading: Symph is a relevant conversation when the change should happen inside tools employees already use. Ask which integrations the proposed team has actually delivered and which need discovery. A promise to connect a CRM is incomplete until the proposal identifies the objects, permissions, write operations and error conditions involved.
- Ask for a demonstration using your proposed read and write boundaries.
- Clarify which monitoring and maintenance tasks are included after handover.
- Request an explicit plan for a vendor API change or expired connection.
3. Senti AI: custom AI and managed operation
Senti AI lists custom AI development, machine-learning and data pipeline engineering, along with management and monitoring of deployed customer solutions. Its service page lists a Makati address.[4]
Kooya’s reading: include Senti when the workflow depends on custom AI or data pipelines and you want to discuss ongoing operation. The reviewed page does not by itself establish a particular tool-using agent architecture. Ask whether the proposed engagement includes action-taking orchestration, business-system connectors and approval controls, or whether those sit outside the quoted AI service.
- Separate model or pipeline work from the workflow orchestration scope.
- Identify whether your team or the supplier owns business-tool integrations.
- Ask what managed monitoring covers and how incidents are escalated.
4. Stratpoint: an AI component within a wider application
Stratpoint’s AI page describes language-model work supported by software, cloud, data and quality-assurance services. It lists managed AI chatbots and enterprise LLM setup, including assistant and information-retrieval functions.[5]
Kooya’s reading: consider Stratpoint when the agent would be part of a larger application or cloud programme. Distinguish a conversational or retrieval interface from software that can write to other systems. The public page is not evidence that a particular action-taking agent or integration is included; get that boundary written into the proposal.
- Ask how the proposed agent fits the existing application release process.
- Request the boundary between chatbot functionality and tool execution.
- Identify responsibility for integration tests and production incident response.
Give every company the same action contract
Kooya recommends a short action contract before requesting a polished demo. List each tool, the data it may read, the exact action it may propose or execute, and the approval required. Describe when the system should stop. This makes proposals comparable even when vendors use different meanings for “agent.”
Consider a hypothetical distributor receiving a stock enquiry. The agent may read the approved product catalogue and inventory view, then draft a reply. It may not reserve inventory, change a price or send a message without the agreed authorisation. A successful trial shows those boundaries holding when the request is incomplete or the stock service is unavailable.
For a team serving customers in English, Filipino or mixed language, use representative permitted examples in the trial. Define what a correct outcome means for the business. Do not assume that a fluent answer demonstrates correct tool use or that a vendor’s generic language claim covers your terminology.
- Read: permitted systems, records and fields.
- Propose: the draft action and the evidence a reviewer sees.
- Execute: who authorises it and how that authorisation is checked.
- Stop: missing information, conflicting records and unavailable tools.
- Record: the outcome, approvals and information needed for support.
Run a rehearsal that includes failure
Kooya’s suggested evaluation is a small, agreed set of realistic tasks with expected outcomes. Include a normal request, a missing record, an unavailable integration, a repeated submission and a request outside the permitted scope. Ask the team to show the trace and the final state in the business tool, not just the conversation.
For repeated submissions, ask how the design prevents a duplicate action. For an unavailable service, ask what is retried and who sees the unresolved case. For approval, test that the system cannot quietly continue when the approver rejects or never responds. These are proposed acceptance questions, not claims that every listed vendor already provides the controls.
Agree the pass conditions before the rehearsal. Keep a record of which cases were tested, which remained unresolved and who accepted any limitation. A supplier who clearly explains an unsupported action gives you more useful information than an unrestricted demo with no trace.
Use the AI pilot evaluation checklist to document the rehearsal, acceptance criteria and release decision.
Agree operating ownership before signing
Kooya recommends separating build completion from operating responsibility. The contract should identify who can change prompts and tools, who rotates integration credentials, who watches failed runs and who owns the response when a model or API changes. Ask how costs are reported and which usage assumptions underpin the quote.
Request a handover inventory covering configuration, source code where agreed, test cases, integration permissions, deployment instructions and support contacts. Decide how your organisation can stop the agent without losing access to the underlying business system. Confirm what happens to records and credentials when the engagement ends.
If the workflow fits Kooya’s approach, bring the action contract and a few representative permitted examples to the first meeting. We can discuss the smallest working slice and the evidence it should produce. Treat the shortlist as a way to begin that conversation; choose the delivery team on the proposal and evidence for your own system.