Docs/Concepts

Agents

Agents

Research in intellectual property means investigating large amounts of highly complicated inventions and papers. Historically that meant employing large research teams to scan and evaluate thousands of documents. Research agents break with that historic pattern by letting you spawn intellectual workers on demand to tackle almost any repetitive task a human researcher could do.

You interact with agents by simply giving them a task or a goal and letting them work for minutes or hours to complete it. They can search for patents, browse for products, launch web browsers, screenshot websites, download files, build claim charts and store every research finding in tables, notes and dashboards to present their results to you.

Before launching an agent you should make a conscious choice about the model you want to use. We offer every state-of-the-art model from all major AI labs. However, they all have different costs, as well as strengths and weaknesses. In general you are billed for every input and output token that a research agent uses. You can find a detailed overview of the associated costs on the pricing page.

Research agents work in a well-defined data model that is provided to them as part of the harness. The data model is described in detail on this page, but we will give a short overview here as well. The goal of each research agent is to populate a research. A research contains a collection of data records, such as patents, products and other objects, as well as attributes that enrich these records, e.g. a custom classification of patents. Records can be mapped to each other to create connections between them. For example, to determine the protective scope of patents, we create mappings between a product and a patent by building an infringement claim chart for them.

On top of the data, the research also contains conclusions and presentations of this data. Each research contains a set of pages that can be one of the following:

  • A table of patents or products presents the data records as rows with attributes and mappings as columns. Tables are often the most intuitive way to present research results.
  • A dashboard to visualize data with all sorts of charts, e.g. line, bar, donut, complex sankey charts or network graphs. Mappings between data records can also be charted.
  • A note to present research findings as rich-text documents with integrated tables and charts. Notes are often used for executive summaries or follow-up tasks.

Agents inform you about their progress as they run. You can leave the window open or even open and run multiple agents in different windows. While an agent is running, it keeps track of its progress via a to-do list that it ticks off as it goes. If you notice the agent going in the wrong direction, you can press control + c at any time to abort the agent and follow up to correct it.

You can also press the Stop button at the bottom right of the composer. Wherever you press it, on the web or in the desktop app, it stops the agent along with its subagents, the deep web searches it started, its browsers and its monitors, and anything it runs on your computers. Control + c only stops the agent in the window you are working in.

While a subagent, a workflow or a deep web search that the agent started is still running, the agent can put a monitor on it and end its turn. The monitor then wakes the agent with what changed, e.g. when a subagent finished or a deep web search found its matches, and ends together with that work. Until then the agent is listed as working in the sidebar.

Closing an agent window, however, never stops an agent. It keeps working, and you can open it again at any time, e.g. from the top of the sidebar, which lists the agents that need your feedback, are working, finished recently or are scheduled, or from the research it belongs to. Be aware that a run in the browser on your own API key or in local storage mode happens right inside the browser tab, so closing or reloading the tab ends it.

Skills#

Research agents often share common workflows that require the same steps to be completed to reach a result. To unify their approach, we provide a set of standard skills that an agent can learn to complete a specific workflow more effectively.

Skills are fully compatible with your existing skills from Claude. They are basically just a collection of markdown files that describe a particular workflow or extend the agent's knowledge. We provide a set of standard skills that cover the most important patent research use cases. Here are some examples:

  • Freedom-to-Operate takes one product, design or idea and works out which third-party patents might read on it.
  • Infringement Detection starts from a single patent or a portfolio you hold and finds the products infringing them.
  • Patent Classification maps a collection of patents into a custom taxonomy of labels or classifications.
  • Infringement Claim Charting explains to the agent how to draft litigation-grade infringement claim charts for mapping a patent to a product.

There are many more standard skills that we provide to your research agents out of the box. Go to Settings > Skills to explore all of them.

Connectors#

Agents thrive on data. That is why we provide the most important data sources like a global patent database or deep web search as part of the harness. However, you can extend the data sources of your research agents by adding connectors.

Connectors allow your research agents to read and interact with external services. They are based on the Model Context Protocol (MCP), which means you can plug in any service that provides an MCP server.

We provide a pre-configured set of connectors that you can simply turn on to allow your research agent to access the data source:

  • Semantic Scholar: Search 200 million scientific papers with citations and abstracts.
  • BioContextAI: Life science databases: Europe PMC, UniProt, ClinicalTrials.gov, openFDA and more.
  • EMBL-EBI InterPro: Protein family and domain annotation, with InterProScan for new sequences.
  • EMBL-EBI OLS: Biomedical ontology lookup: ChEBI chemicals, GO terms, and more.
  • Wolfram: Wolfram Alpha computation and curated knowledge.
  • DrugBank: Drug, target, and interaction data from DrugBank.

Memories#

Research agents learn over time to adjust to your research style and preferences. However, they don't train the underlying base model. Rather, they store a collective set of memory files that other research agents can read and write to share what they have learned.

A memory is simply a short markdown note with a name, e.g. a naming convention you prefer, what a client decided and why, or which assignees turned out to matter in a field. Every agent starts with the list of memory names, reads the ones that bear on its task and writes new memories or edits existing ones as it goes. Research findings do not belong in a memory. They belong in a note inside the research.

Memories are yours and belong to the organization you are working in. Every agent you run there shares them, subagents included, while your colleagues keep their own set. You can keep up to 100 memories per organization. With local storage mode on, they are stored in your browser or on your device instead of in the cloud.

You can read, edit and delete any memory at any time by going to Settings > Memories. New memories are written by the agents themselves.

An app you connect over Model Context Protocol reaches the same set through the memorize tool, so a memory written in Claude or ChatGPT is there the next time an agent runs in Patalyze. Listing and reading them needs the research:read scope and writing one needs research:write, so an app granted read access alone can never change one.

Subagents#

A research agent can fan out subagents to delegate work. You can explicitly instruct the agent to spawn subagents to research specific tasks in more detail or simply let the agent decide when to spawn them.

Each subagent gets a fresh context window and works with the same tools, skills and memories as its parent, in the parent's research if it has one. Connectors are only available to the parent. A single fan-out can start up to 25 subagents, and a subagent cannot spawn subagents of its own. For work in stages, where each stage builds on the answers of the previous one, the agent can also start a workflow. A workflow is a small script that starts up to 96 subagents over several rounds on its own, and it shows up as a single row among the subagents. Its subagents send what they found to the conversation that started the workflow, just like the subagents of a fan-out.

An agent doesn't need a research to fan out. Without one, its subagents simply search, read and report back, e.g. for a prior art search from several angles or to check the products a deep web search found. Once the agent starts a research, its subagents and workflows move into it together with the agent.

The parent picks a model for each subagent and matches it to the work, e.g. a capable model for claim charting and a cheaper one for filling a column across many patents. In the cloud that can be any of our models, and on your own API key or subscription any model of that provider. Like the parent, each subagent is billed per input and output token of the model it runs on.

Subagents tell the parent agent what they found by sending it a message, and the parent decides what to do next. Each message shows up as its own row in the parent's agent window, with the name of the subagent that sent it. A subagent that sends nothing reports nothing, so the parent tells each subagent in its task what to send. While they work, subagents can also send a short note to the other subagents started in the same run, or to the other agents of the same workflow.

Agents can also reach beyond their own fan-out. An agent can send a message to any agent working in a research you can edit, including the agents of colleagues who share that research with you, and in that case the row names your colleague as well. It can also read the transcript of any agent in a research you can open, e.g. to see how far another agent has got before it builds on that work.

A question a subagent cannot settle itself surfaces in the parent's agent window. It carries the subagent's name, shows up wherever you have that conversation open and is e-mailed to you like any other question. When several subagents ask the same question, you only see it once, and your answer goes to all of them. Subagents can e-mail you directly, though normally the parent decides what is worth telling you.

Active subagents are shown at the bottom of the agent window. While a subagent runs, its row shows the time elapsed so far, and a subagent running on your computer or with your own API key also shows the tokens it has used. You can click on each subagent to observe the current state and direction. With several subagents this opens their list, which shows the tokens each one used once it has finished. Upon completion the subagents disappear from the agent window, and the messages they sent stay in the conversation.

Local vs cloud#

Research agents can either run on your local device or in the cloud. You can enable local execution by turning on local storage mode under Settings > Data controls. With local storage mode on, research data, skills, connectors and memories are only stored in your browser or, in the desktop app, on your device. Real-time collaboration and cloud agents are disabled, and research agents run in your browser or in the desktop app instead.

Be aware that the underlying model is cloud-hosted unless you configure an on-device model. We provide every frontier model out of the box, and you configure which model you want to use under Settings > Models. If you prefer to use your own API keys, you can also add an Anthropic, OpenAI or Gemini API key, or, in the desktop app, your Claude or ChatGPT subscription. Your keys stay in your browser, or in the operating system's keychain in the desktop app. They are never stored on our servers.

Runs on your computer#

A Claude or ChatGPT subscription only works in the desktop app, but you don't have to sit in front of that computer to use it. Every computer that runs the desktop app on your account is listed under Settings > Devices, together with the subscriptions and API keys connected on it. On the web or on another computer, you can then pick one of them to run your agent, and the run is sent to that computer. You follow it, answer its questions or stop it from where you sent it, just like any other agent.

It also works the other way around: a run you start in the desktop app shows up on the web as well. A follow-up you send from the web or from another computer continues on the same computer.

The computer does not need to be on when you send something. While the desktop app on it is not open, the conversation says so and your message waits, without a deadline, until the next time the app opens on that computer. In the meantime you can add another message, or press Stop to call it off. Removing the computer from your devices cancels what is waiting for it and pauses its schedules.

If the computer goes to sleep, loses its connection or the desktop app is closed during such a run, the run waits in the same way and continues where it stopped once the computer is back. You can still answer its questions while it waits, and the conversation notes when the run continued. A run you started in the desktop app itself on your subscription or API key, on the other hand, ends when you quit the app.

Messages#

You can send an agent a message at any time, even while it is still working. Press enter and the message is queued. It shows up at the end of the conversation, and as long as the agent has not read it yet, you can take it back with "Queued, remove". You can queue up to 16 messages at a time.

An agent in our cloud reads your message while it works, even while it waits for its subagents, and takes it into account. When the agent runs in your browser or on one of your computers, your message waits until the agent has finished. So does a message with files or skills, a message you send after switching a connector on or off, and every message queued after it.

When a run has finished, or failed, the agent starts its next run with all queued messages at once. After you press Stop, they stay queued instead and go out together with your next message. With local storage mode on, queued messages are sent one at a time, each as soon as the run before it has finished or was stopped.

A question that waits for your answer takes the place of the composer, so you answer it first or press control + c to stop the agent. When an agent has stopped responding for five minutes, your message does not wait for it. It stops that run and starts a new one, while subagents, deep web searches and browsers from earlier runs keep going.

Scheduled runs#

A lot of patent research has to be repeated, e.g. watching a competitor's new filings every week. For that you can put an agent on a schedule. A schedule belongs to one conversation and sends it the same instruction at the times you set, so every run can build on what the earlier runs found.

You set up a schedule by simply asking the agent, e.g. "Look for new patents on solid-state batteries every Monday at 9:00 and tell me what changed", and it is active right away. You change, pause, resume or delete it the same way. A card in the conversation and the Scheduled section in the sidebar show when it runs next. A conversation on your own API key in the browser or in local storage mode cannot be scheduled, because nothing could start it while you are away.

For new patents the agent simply searches again on every run, with a publication date filter that covers the time since the previous run, and adds what it finds to your research, so whatever was not there before is new. For new products it lets the deep web search repeat itself every day, week or month, which only collects products it has not found before, and the scheduled runs then go through those new matches.

A schedule can run once or again and again, every few hours, days, weeks or months, at the time of day you want and in your own time zone. You can keep up to 25 schedules of your own in each organization. Each one runs where its conversation ran when you set it up or last resumed it, in our cloud using your organization's AI & Data usage or on one of your computers. If that computer is off, the run waits for it, and later runs that fall due in the meantime are skipped.

Since you are usually not around when a scheduled run happens, the agent only asks you something when it cannot go on without a decision. It e-mails you the result when there is something you should see, as your "Agent reports" setting allows.

A schedule pauses after three failures in a row, or after the first one when it can no longer run at all, e.g. because you lost edit access to its research. Pressing Stop ends only the current run and does not count as a failure. Once you have fixed the cause of a pause, ask the agent to resume the schedule.

Notifications#

When an agent needs input or wants to share its results, but you don't have the application open, it can send you an e-mail.

There are three kinds of e-mail. A report is sent when an agent finishes a task, one e-mail per task from Patalyze's own address, and an agent can address it to colleagues by name as well as to you. It can only reach people in your organization who already have access to that research, and only those who have agent reports switched on.

A question is sent when an agent needs a decision from you and the conversation is not open on your screen: it waits about a minute and then e-mails you the question with a link back to the conversation. A schedule e-mail is sent when one of your schedules starts failing and when it is paused, as described under Scheduled runs.

All three can be configured under Settings > Notifications. "Agent reports" can be set to Always, Only critical reports or Off, where critical means that an agent only writes when a run failed or needs a decision to continue. "Agent questions" can be set to Always or Off. Schedule e-mails follow "Agent reports" and stop only when it is set to Off.

External MCP client#

We already introduced Connectors, which allow you to connect your research agents to external MCP servers. You can also switch it around and connect to Patalyze from an external MCP client.

That means that you can use Patalyze from ChatGPT or Claude without the need to use our agent harness or UI. The external MCP client will provide and drive the agent loop while Patalyze provides the data and tools to conduct professional patent research.

To get started, simply open Claude or ChatGPT and tell it to set up Patalyze. The agent will automatically figure out how to install everything it needs.