Most agent projects start with a model and a prompt, then grow extra capabilities one incident at a time: search after the first stale answer, an approval step after the first unwanted email, logging after the first “what did it just do?”. Choosing them deliberately is cheaper. This page groups what a working agent needs into seven capability categories, explains what each one is for, and lists what to check before you pick a provider or build your own.
The map
The first four categories give the agent reach: they let it find, read and act. The last three decide what it keeps, what it may do without asking, and what anyone can check afterwards. Leaving out the second group is a common reason a capable prototype never makes it into production.
| Capability | Question it answers | Without it |
|---|---|---|
| Model access | Which model runs this step, and on what terms? | Locked to one vendor, keys scattered through the code |
| Search | Where is the information? | Answers from stale training data |
| Extraction | What exactly does the source say? | Prose summaries where you needed fields |
| Browsing | What does the page show once it has loaded, or after a login? | Blind to interactive sites |
| Memory | What should carry over between runs? | Relearns everything, or remembers the wrong things |
| Approvals | Who decides before a consequential action? | Actions nobody intended |
| Audit | What happened, and on whose authority? | No way to review, debug or answer an auditor |
This page is about choosing each piece. If you are assembling a stack specifically for research and monitoring, a research and monitoring stack covers that combination end to end.
Reach: model access, search, extraction, browsing
Model access
Agents rarely use one model for everything. A planning step, a bulk classification step and a final drafting step have different needs, and models change often enough that switching has to be cheap. What you want is a single access point with routing, key management and logging, rather than vendor SDK calls scattered across the codebase.
Check when choosing:
- How your data is handled: retention, use for training, region.
- Tool-calling reliability on your own tasks, judged with your own test set rather than a public leaderboard.
- Whether you can switch models per step without rewriting prompts and output parsers.
- Whether every call is logged with enough context to reproduce it later.
Search
Search splits into two distinct needs. Open-web search finds current public information and comes from a web search API or a self-hosted index. Knowledge search finds information in your own documents, where the web is irrelevant and access control matters a great deal. Most serious agents need both, with a clear rule for which questions go where.
Check: results returned as passages rather than bare links, freshness controls, domain or source restrictions and, above all, quality on your own queries. A small set of real questions with known answers tells you more than any feature list.
Extraction
Search finds the page; extraction turns it into something a program can use, such as a renewal date, a list of executives or a price table. The difference between a strong and a weak extraction capability shows in how it handles absence. A strong one returns unknown when the source does not state a value. A weak one returns a plausible guess.
Check: a schema you define, the supporting passage returned with each value, explicit unknowns, and behavior on messy inputs such as scanned PDFs or tables split across pages. Structured data extraction with AI covers the techniques.
Browsing
Some information only exists after a page runs its scripts, or behind a form, a filter or a login. A headless browser or a browser agent handles that, at a cost. It is slower, more fragile and much riskier than a plain fetch, because a browser can click “submit” as easily as “next page”.
Check: whether you can limit the sites a session may visit and the actions it may take, whether sessions are isolated from one another, how credentials are supplied (ideally as server-side references the agent never sees), and whether consequential clicks pause for a person. A URL inside a task is not permission to get past a login; access should be granted explicitly, task by task.
Control: memory, approvals, audit
Memory
Memory makes agents feel competent, and it causes their subtlest failures. A preference mentioned once in a chat hardens into a permanent rule. A fact from one project leaks into another. A stale figure gets reused for months.
Check: scopes such as session, user, project and organization, with the narrowest as the default; new memories held as proposals with a source until someone approves them; corrections that create a new version instead of overwriting; and expiry. Memory should never stand in for a fresh lookup when the answer depends on current facts. Memory with consent describes the approval model.
Approvals
An approval capability decides which actions pause for a person and records each decision. The hard part is drawing the line. Pause on everything and people approve without reading; pause on nothing and the first mistake leaves the building.
A practical line is a short list of consequential action classes: sending something out, deleting, exporting data, scheduling recurring work, acting in a live session, changing the agent's own instructions and handing work to another agent. Check that an approval covers one specific attempt, that it is checked again when the action actually executes, and that the approver sees the exact call being made rather than a paraphrase. The note on the seven action classes goes through each one.
Audit
Audit is the record that lets you answer, weeks later, what the agent did, on whose authority and with what result. It is not the same as application logs, which are written for engineers and rotated away.
Check: one continuous trail that joins the request, each tool call, each decision (rejections included) and the outcome; entries written as events happen rather than reconstructed afterwards; and a reading view that someone outside engineering can use. What an agent audit trail should record lists the fields.
Where GoCux covers the map, and where it does not
GoCux is a company workspace, not a supplier for every row of the table, and it helps to be precise. It does not crawl the web, run a web search API or act as a model. Open-web search and crawling come from elsewhere, and web material enters a project through an authorized browsing or export step together with its page reference and retrieval date.
What it does provide is the control half of the map, plus evidence-first tools over your own material: Knowledge search across a project's documents with citations; extraction in which every value carries its supporting passage and missing values stay unknown; a Memory Graph that keeps proposed memories apart from approved ones; approval gates on seven consequential action classes; and one audit trail covering requests, decisions, tool runs and outcomes. Work stays inside a company boundary, draws on visible credits under a daily cap, and can be halted with a single stop control. Governance describes the gate and the trail in detail.
Choosing in a sensible order
- Write down the agent's goal and acceptance criteria. They decide which capabilities you need at all.
- Start read-only: model access, search and extraction, with no write tools.
- Add audit before the first real user, so every run is readable from the start.
- Add approvals before the first write tool, not after the first incident.
- Add browsing only for the sites that need it, with per-task grants.
- Add long-term memory last, narrowly scoped and with approval.
- For each category, test candidates on your own tasks and keep that test set. You will reuse it every time a provider or a model changes.
Bring this workflow into your workspace.
Set the scope. Review the evidence. Approve the steps that need it.