deep.navy

Seven agents you can build with one data connection

Practical workflows for supplier risk, site screening, market expansion, competitive research and more, with the inputs and outputs each agent needs.

· deep.navy · 5 min read

The interesting part of a data agent is the second question. A storm is approaching: which facilities are exposed? A company filed an 8-K: does it change the research thesis? A vendor changed its pricing page: which assumption in our budget needs review?

deep.navy puts news, filings, web history, company records, weather, economic indicators, energy statistics and geospatial catalogs behind one MCP endpoint. Your agent supplies the joins and reasoning. Your business supplies the context that public data cannot know.

These seven workflows are build ideas using the current tools, not prebuilt applications or claims about customer results. Each ends in something a person can inspect.

1. A supplier disruption desk

Start with supplier legal names and a verified facility list from your procurement system. Use company_search and company_fetch to check entity matches; geo_places to disambiguate regions; and weather_alerts for US facility coordinates. Add news_search for company names and disruption terms, then web_fetch for the original reports.

The output is an exposure queue: supplier, affected facility, source, event window and the question for procurement. Keep a headline about a supplier’s headquarters separate from evidence about the factory that fulfills your order. The company guide explains GLEIF coverage; the weather guide bounds the NWS tools to supported US locations.

Starter prompt: “Which verified supplier sites need a check today? Show the evidence linking each event to that site, and mark missing links unresolved.”

2. A site-screening assistant

Give it candidate coordinates, electricity needs and the criteria your team already uses. Combine geo_search and geo_fetch for available scenes and station records, energy_fetch for state-and-sector electricity benchmarks, and news for documented local developments.

The output is a comparison brief with source coverage, capture dates and unanswered questions. STAC returns scene metadata and asset links; imagery analysis requires a separate geospatial tool. A scene’s cloud-cover percentage is not a building inspection, and a short weather record is not a long-term hazard model. The STAC specification explains the catalog structure; our geo guide lists the supported datasets.

Starter prompt: “Compare these three sites against my criteria. Separate measurements, public benchmarks and unavailable evidence. Do not turn missing records into a favorable score.”

3. A market-expansion researcher

Start with a product, two countries and a decision window. Discover supported indicators through worldbank_search, then use worldbank_fetch for comparable annual population, GDP growth, inflation or trade observations. Add recent reporting and source pages through news and fetch.

The output is a country comparison with explicit years and definitions, followed by questions for local research. Annual country indicators cannot establish the addressable market for a particular product. Use your own customer and distribution data for that step. The World Bank guide explains missing values, revisions and the reviewed indicator catalog.

Starter prompt: “Compare the same available years for both countries. Identify what changed, cite the definition of each indicator, and list what this data cannot tell us about our customers.”

4. A competitive-change notebook

Give the agent a small list of public pricing, product and documentation URLs. On your own schedule, call web_fetch, record the returned version, and later use web_versions and web_diff to compare stored versions. Ask the agent to separate substantive changes from navigation and formatting noise.

The output is a dated change log with links and before/after evidence. The first fetch starts your observation history; it does not reconstruct changes from before that visit. The fetch tools describe supported content, versioning and output limits. Website polling needs your scheduler; deep.navy monitors do not accept a web-page query.

Starter prompt: “Compare the two stored versions of each page. Extract changed prices, limits and product commitments, and quote only the short passages needed to verify the change.”

5. A research-thesis watchdog

Give it a thesis, the company’s identifier, and the observations that would weaken the thesis. Use EDGAR and news searches to establish a baseline, then save supported queries with monitor_create. Your webhook consumer asks the agent to evaluate each new match against those written conditions.

The output is a “revisit this assumption” note with a filing accession or article link. A monitor match is a research event, not a buy or sell instruction. Watch the actual indexed EDGAR coverage, and follow the monitor guide for signatures and delivery handling. The investment research tutorial gives the full workflow.

Starter prompt: “For each new match, identify which thesis condition it affects, cite the evidence, and include the strongest alternative explanation.”

6. A budget-context agent

Combine your invoices and budgets with EIA benchmarks, current US weather and supplier identity records. The output is a short exception report: a cost variance to reconcile, a contract assumption to revisit, or an identity match to confirm.

Public averages provide context; your contracts determine your obligations. The finance briefing tutorial includes tool requests and a worked, explicitly hypothetical sensitivity calculation.

Starter prompt: “Explain the largest budget exceptions using our records first, then external context. Distinguish arithmetic from assumptions and identify the person who can resolve each open question.”

7. A weather-and-energy research agent

Combine an explicit asset-exposure map with NWS forecasts and alerts, EIA storage or generation observations, geospatial catalog results and relevant filings. Produce a hypothesis card: mechanism, time horizon, confirming evidence and conditions that would disprove it.

Price history, expectations, transaction costs and execution come from your separately licensed market-data and brokerage systems. The energy research tutorial shows how to keep those boundaries clear while building something testable.

Starter prompt: “Identify one weather-related hypothesis for these assets. Show the exposure chain, source times and disconfirming evidence. List the price and expectations data needed before testing a trade.”

Build one narrow loop first

Connect your client, enable the needed toolsets, and choose one workflow with a small input list. Save a baseline artifact, then run it again when the underlying evidence changes. Evaluate whether it found a useful change, supported it with the right source, and expressed uncertainty when the join was missing.

For Claude Code, after creating a tool API key in the dashboard and setting it as DEEPNAVY_KEY in your shell, add the connection:

claude mcp add --scope user --transport http deepnavy https://mcp.deep.navy/mcp --header "Authorization: Bearer $DEEPNAVY_KEY"

User scope makes deep.navy available in every project; --scope project writes a shareable .mcp.json for a team repository instead. Keep credentials out of committed configuration. Other clients have setup instructions in the connection guide.

The scheduling belongs to your agent application. Native monitors currently support news, EDGAR and supported synced geo queries; weather, EIA and World Bank refreshes need your application’s scheduler. Treat retrieved text as untrusted evidence, preserve source links and timestamps, and keep customer records in your own system.

If you are building this for customers’ agents, the Platform API lets your backend issue tenant-scoped keys and inspect usage. Start with one deliverable people want to read. Expand the tool chain when a specific unanswered question requires it.

Every post RSS feed This post as Markdown