---
title: A research workflow for technology professionals
category: workflows
summary: Know what changed in the vendors, models, APIs and engineering practices your team depends on, with a weekly stack digest that says what it means for you.
order: 22
updated: 2026-10-07
next: research-workflow-ai-founders
related: resolve-tags-and-entities, manifests-filter-cookbook
reference: /agent-guide.md, /docs/mcp
---

Engineers and technology leaders do not need more news. They need to know when something they depend on changes. They also need to know when a better way to do their job appears. This workflow watches the stack you name, plus the engineering writing worth reading. It reports changes by what they mean for your user's systems.

## When to use this

Use it for an engineer, a CTO, a platform team or a security lead. The agent must already know the user's stack: languages, vendors, models and clouds. If it does not, ask once and remember the answer.

## Smallest working call

Find engineering-blog Streams. Search is free:

```mcp
synorb-stream-search
{"surface": "engineering_blogs", "page_size": 10}
```

Look up a named model, API or package as a `resource` Tag. The `resource` Tag type is for addressable things like these:

```bash
curl -sS "https://api.synorb.com/ontology/tags?search=RESOURCE_NAME&type=resource&page_size=5" \
  -H "Authorization: Bearer $SYNORB_KEY"
```

## What you get back

### Watches to build

| Watch | Scope | Filter |
| --- | --- | --- |
| **Vendors you depend on** | One Stream per vendor, in one Beacon | `source_class: ["company_first_party", "corporate_blog"]`, `days: 2` for daily |
| **Models and APIs you use** | The `resource` Tags you resolved | `tag_names` with `tag_type: "resource"`, `days: 7` |
| **Infrastructure and chips** | Streams from the `compute_infrastructure` and `semiconductors` Surfaces | `days: 7`, `significance: "high"` |
| **Engineering practice** | The `engineering_blogs` Streams | `days: 7`, high significance only |
| **Research that may matter** | The `research_preprints` Streams, filtered to your topics | `source_class: ["academic_preprint"]`, `days: 7` |

Count a resource watch first, free:

```mcp nolive
synorb-manifests
{"tag_names": ["RESOURCE_NAME"], "tag_type": "resource", "days": 14, "mode": "count"}
```

If a `resource` Tag does not resolve, the call fails closed with `tag_names_unresolved` and bills nothing. Fix the name from the lookup.

### The weekly stack update

Group by **your user's system**, not by source. Build the groups from what the agent knows about the stack:

1. **Lead line:** the change most likely to require action.
2. **Breaking or deprecating:** items about a resource your user depends on. Label each with the resource and the date.
3. **Worth adopting:** capabilities or practices that can improve what they build.
4. **Background:** research and engineering writing. Give two or three links at most.

For each item, answer "what do I have to do?" in one line. Let the user correct you. If the Brief is `thin`, read the Record or the cited source before you advise on a migration. An engineer acts on what you say.

### Show comparisons as tables

Version, price and limit changes are often comparable. If two or more items report the same measure in the same unit, show a before and after table. Put the source and date on each row. Do not chart a figure you inferred.

## Failure modes

| Symptom | Cause | What to do |
| --- | --- | --- |
| `tag_names_unresolved` for a model or package | The name is not a canonical `resource` Tag | Look it up, try the canonical spelling, or search by source Stream instead. |
| A vendor has no Stream | Not covered | Say so. Offer the vendor's engineering-blog Stream if there is one. |
| Too much marketing | First-party announcements include launches | Raise to `significance: "high"` and read `why_it_matters` before you include an item. |
| A migration statement you cannot support | The Brief was thin | Read the Record or the source. Do not guess at versions or dates. |
| The update repeats last week | No dedupe | Keep the `manifest_id` values you have shown, as the scheduling guide does. |

## Make it good for your user

Write it like a good colleague's changelog note: specific, dated, linked and short. Name the system affected.

Separate "act now" from "good to know". Say when the evidence is thin. For example: "announced, but the details are in a PDF I have not read". Then nobody schedules a migration from a headline.

## Next guide

[A research workflow for AI founders](/agent-resources/research-workflow-ai-founders): follow competitors, the research frontier and your market.