An agent research workflow starts with a specific question and returns evidence the user can inspect. The company record and the assistant’s interpretation serve different purposes. Keep them separate so fluent prose does not hide an unresolved identity or missing field.
Start with a verified workspace at app.vencavo.com. Follow the MCP setup guide or REST quickstart to authorize your client. Define the company and contact fields your task needs, then agree on a search-page and unlock budget. The browser demonstrations use fictional records.
Define a bounded lookup
Use the task to choose the input and result scope:
- Identify the company or research criteria from the user’s question.
- Select the operation and supply explicit inputs.
- Apply the agreed authorization, validation, and result limits.
- Preserve the returned record, source context, and unavailable values.
- Write an answer that distinguishes supplied facts from interpretation.
- Return unresolved questions for review before a consequential action.
The MCP reference documents implemented search_companies and get_company requests. The API overview addresses applications that manage their own request flow. Use the app origin https://app.vencavo.com and its current schemas. Keep credentials out of the marketing website.
Keep documentation and data access distinct
| Component | Role in the workflow |
|---|---|
| HTML and Markdown docs | Explain fields, examples, and integration requirements |
/llms.txt |
Index the documentation destinations |
| Application API | Define the application’s request and response contract |
| MCP tools | Expose a bounded capability to a compatible agent client |
| Workflow instructions | Specify how to use a result and when to ask for review |
The llms.txt proposal describes a documentation convention. The website’s index does not provide dataset access, authenticate a caller, or register a tool with a client.
Work through an account-research question
The fictional question is: “What should I know about Forma Labs before an account review?” The input domain is forma.example.
The sample company record contains Forma Labs, SaaS, San Francisco, US, and an employee band of 51–200. The connected people example names Maya Chen, VP Sales. Her manager and buying responsibility are not supplied. Neither the sample title nor the employee band establishes current need or intent.
A reviewable handoff contains the returned values, a clearly labeled interpretation, and questions the record cannot answer:
| Handoff section | Example |
|---|---|
| Supplied context | Fictional company identity, industry, location, and employee band |
| Role context | Fictional VP Sales membership, with manager unknown |
| Interpretation | A candidate account to research against the user’s criteria |
| Unknowns | Product fit, need, budget, reporting relationships, and verification dates |
| Next step | Seek attributable evidence for the question that matters to the account review |
Keep the original record beside the brief. The company research worksheet provides a ledger for this handoff. The account/org mapping guide keeps membership separate from reporting lines.
Handle incomplete and unsuccessful results
If the company identity is unresolved, request a better identifier or return an unresolved result. Do not reuse an unrelated record with a similar name.
If a field is missing, retain its documented unknown state. Do not turn an absent event date into today or a missing headcount into zero. The data model separates event, observation, and verification times.
If a service request fails, report the unsuccessful lookup and apply the agreed error and retry contract. A generated summary is not a fallback data source. Any external action needs its own supported integration and review rules.
Prepare your first research task
Bring representative questions, required fields, expected request volume, client environment, and acceptance criteria. Include failure cases, unresolved identities, and missing-value handling in the evaluation.
Use the data evaluation reference to frame evidence and freshness requirements. Use the MCP guide to connect your client, or the REST quickstart for your first request. Contact support for separately scoped requirements.