DEV Community: Alexander Prokofiev

What happens to an agent’s PASS after a dependency upgrade?

Alexander Prokofiev — Tue, 29 Sep 2026 23:26:58 +0000

A PASS is a statement about an observation. It is not a permanent property of a package, a service, or a fix.

If an agent reports that a workaround passed with dependency version 3.2, then the dependency moves to 4.0, what should the next agent believe? Deleting the old PASS loses useful history. Reusing it as evidence for 4.0 silently widens what the observation actually proved.

The useful answer sits between those two mistakes: keep the historical result, keep its scope attached, and require new evidence before claiming the new version passes.

In an earlier post about sharing a task between Claude and Perplexity, I wrote about a related boundary: two agent identities under one operator show interoperability, but do not establish two independent reproductions. The follow-up discussion sharpened the problem. Who observed a result, what evidence grounds it, and whether it applies to the current dependency are separate questions.

A version change opens a new evidence question

Suppose a report says a workaround passed with example-package@3.2. The package is now at 4.0, and nobody has rerun the relevant check.

The old result is still meaningful. It says a particular observation passed against 3.2 in a recorded environment. It does not answer what happens on 4.0. Until somebody runs that check, the 4.0 state is unknown. Unknown is not a failure; it is the absence of a new observation.

Here is a small illustrative design, not a real execution record or a current API contract. The identifier-like values are fictional placeholders that bind an outcome to the exact claim and check revisions; they are not hashes and do not prove correctness:

observation:
  id: illustrative-observation-1
  claim_id: illustrative-claim-1
  claim_revision: 1
  check_id: illustrative-check-1
  check_revision: 1
  dependency: example-package@3.2
  outcome: PASS
  environment: <captured environment>
  evidence: <sanitized execution record>
  lineage: executed_here

derived_applicability:
  dependency: example-package@4.0
  claim_id: illustrative-claim-1
  claim_revision: 1
  check_id: illustrative-check-1
  check_revision: 1
  status: NOT_ESTABLISHED
  basis: no observation for 4.0
  related_history: illustrative-observation-1

The second block is a derived applicability view, not an observation: it does not overwrite or revoke the historical PASS, and it records no 4.0 run. If someone runs the check at 4.0, that should create a new observation with its own environment and evidence. A PASS or FAIL then describes that run. Editing the proposed fix or the check creates a new claim or check revision and therefore a new evaluation subject, even if the package remains at 3.2. If two runs disagree under what appears to be the same conditions, record an unresolved conflict and investigate the missing variable. “Newest wins” would hide the question that needs answering.

Three design decisions that keep the record honest

1. Bind an outcome to the thing and context that were tested. A result should identify the dependency or service version, the relevant configuration, and enough environment detail to judge whether another run is comparable. When available, include a build or artifact identifier, source references, and a sanitized record of what was executed. “It passed” without a subject and context is difficult to reuse safely.

2. Preserve old evidence without carrying its scope forward. A version change is a reason to ask a new question, not a reason to erase history or claim the next version failed. Not every meaningful change arrives with a neat version number: hosted APIs, model behavior, authentication policy, regional behavior, and infrastructure defaults can move independently. A date can help locate an observation, but age alone does not establish staleness. Prefer an explicit “not rechecked against this change” state to automatic decay that pretends to know what changed.

3. Keep lineage and disagreement visible. A second agent may have run a fresh test, inherited the first agent’s transcript, or repeated a source without running anything. Those are different paths. Record whether an observation was executed independently or derived from prior evidence, and preserve the source links. If outcomes conflict, show both observations and the unresolved status instead of averaging them into a score or selecting the newest one. There is no universal trust score that can safely replace the details a particular reader needs.

This also shapes how summaries should work. A compact view can say that 3.2 has a recorded PASS and 4.0 has no observation. But the summary is a view over the evidence, not a new reproduction. The canonical record should remain inspectable and revisions should not silently rewrite what an earlier participant said.

“Immutable” needs a boundary, too. Sanitization should happen before sharing, and a system still needs an explicit way to correct or remove material when privacy, rights, or policy require it. Preserving history is not a reason to keep sensitive data public forever.

What the next agent should inherit

After an upgrade, the next agent should inherit the old PASS with its version and environment, not a broader claim that the fix works now. It should also see what changed, whether a new run exists, and whether any result was inherited rather than independently executed.

That leaves the reader with a useful starting point and an honest boundary: this worked under those conditions; the upgraded dependency remains untested. The old work is not wasted, and the new question is clear.

AI disclosure: AI agents drafted and edited this article from the ideas in my earlier DEV post and its discussion. The new text has not been manually rewritten by me; the schema above is an illustrative design, not a report of an executed test.

Cover image disclosure: AI-generated illustration. The v1/v2 labels are generic; the image does not depict the example package versions or a real test.

I made Claude and Perplexity share a durable task - then hit an identity problem

Alexander Prokofiev — Mon, 14 Sep 2026 22:29:07 +0000

AI agents are getting better at solving problems.
They are still surprisingly bad at remembering what another agent already learned.
I kept running into the same pattern:
Claude debugs something in one session.
Codex discovers the same failure two days later.
Another agent researches the same API limitation from scratch.
The model may be different, the application may be different, but the operational experience is usually trapped inside one conversation.
So I started experimenting with a shared layer where agents could leave structured experience for each other.
Not just documents.
Something closer to:
Problem ↓ Solution ↓ Outcome ↓ PASS / FAIL / limitation
And, for questions that cannot be answered immediately:
Agent A asks ↓ shared durable task ↓ Agent B replies later ↓ Agent A retrieves the reply

That led to an interesting test.
Claude asks, Perplexity answers
I connected Claude and Perplexity to the same shared knowledge layer through agent-facing interfaces.
The flow was:
Claude ↓ creates a durable question ↓ Knowledge layer ↓ Perplexity finds the question ↓ Perplexity replies ↓ Knowledge layer ↓ Claude retrieves the reply later

This was performed through actual hosted AI products rather than two instances of the same local agent framework.
That part worked.
But the more interesting problem appeared immediately afterward.
Two agents do not necessarily mean two independent observations
Claude and Perplexity were different agent identities.
But both were operated by me.
That distinction matters.
Suppose an agent publishes:

This fix works.

Then another agent records:

PASS — reproduced successfully.

At first glance that looks like independent corroboration.
But what if:

both agents belong to the same human;
both inherited the same context;
both were given the same assumptions;
both ultimately relied on the same source;
or one agent simply repeated information produced by the other? Counting that as two independent reproductions would manufacture confidence. So in the system I am building, agent identity and operator identity are separate concepts. The Claude/Perplexity experiment therefore means: 2 agent identities 1 operator = interoperability evidence ≠ independent reproduction

That sounds like a small bookkeeping detail.
I think it becomes a fairly fundamental issue once agents start sharing knowledge with each other.
Successful answers are not enough
There is another thing I wanted the knowledge model to preserve: failure.
Most knowledge systems naturally converge on the final answer.
Agent work often looks more like this:
`Problem

Attempt A
FAIL — wrong API version

Attempt B
FAIL — works locally, fails behind proxy

Attempt C
PASS — environment X, version Y

Later:
FAIL — version Z changed the behaviorFor the next agent, Attempt A and Attempt B may be as valuable as Attempt C. They prevent repeated exploration. So the useful unit of shared agent knowledge is not simply:question → answerIt is closer to:problem
→ proposed solution
→ observed outcome
→ environment
→ evidence
→ limitations
→ provenance`
That also means a system should be able to say:

We do not know.

or:

This worked once under these conditions.

instead of collapsing everything into a single canonical answer.
Why I did not put an LLM in the middle
One design decision was to keep the shared layer itself deterministic.
Reading a stored result should not trigger another model to reinterpret or regenerate it.
If an agent recorded:
FAIL Node 24 macOS spawn npx ENOENT

another agent should be able to retrieve exactly that observation.
The server can structure, index and connect knowledge.
It does not need to invent a new answer every time someone reads it.
That gives a useful separation:
`AI agents produce observations

shared infrastructure stores provenance

other AI agents decide how much to trust and reuse them`
It also makes the knowledge usable by systems with very different models and vendors.
Synchronous tools and asynchronous questions are different problems
This experiment also made another distinction clearer to me.
Sometimes an agent needs:

Search the existing knowledge now.

That maps naturally to a tool protocol such as MCP.
But sometimes the request is:

Nobody has answered this yet. Ask the network and let me come back later.

That is a different interaction model.
The caller needs a durable task rather than a synchronous tool response.
So I ended up treating those as separate primitives:
`MCP:
What does the network already know?

Asynchronous task:
Ask the network and let me return later.`
Trying to force both into one synchronous request makes the second case awkward very quickly.
The part I am still unsure about
Transport is relatively easy compared with trust.
Once multiple agents can share operational experience, several questions become much harder:
How should an agent decide whether another agent's PASS is worth trusting?
How much should operator independence matter?
Should reproduction across different models count more strongly?
What happens when two credible agents publish conflicting outcomes?
How quickly should old outcomes decay when dependencies and APIs change?
And should a failed approach increase confidence in another solution — or simply remain a warning attached to one environment?
Those seem less like retrieval problems and more like social/provenance problems for machines.
The Claude → Perplexity exchange convinced me that cross-vendor transport is possible.
It also convinced me that transport may be the easy part.
The difficult problem is deciding what an agent should believe after the message arrives.

Making a Local Events API Discoverable to Developers and AI Assistants

Alexander Prokofiev — Thu, 21 May 2026 23:14:32 +0000

Local cultural data should not only live as web pages.
That is the idea behind the public discovery layer we just shipped for the DondeGo API.
DondeGo is a local discovery platform for Barcelona and Madrid, focused on events, places, cultural life, and local news. We are building it as a media and discovery product, but we also want the data surface to be understandable by developers, API clients, documentation tools, and AI assistants.
So instead of only publishing a human-readable API page, we built a small discovery package around the API.
It includes OpenAPI, llms.txt, an API Catalog linkset, Postman documentation, examples, and a documentation-only Agent Skills index.
The goal is simple:
make the API easier to discover, understand, cite, and use without pretending to support capabilities that do not exist yet.

What is live

Here are the main public entry points.
OpenAPI 3.1:
https://dondego.es/openapi.json
llms.txt:
https://dondego.es/llms.txt
API Catalog linkset:
https://dondego.es/.well-known/api-catalog
Rich DondeGo discovery JSON:
https://dondego.es/api-catalog.json
Documentation-only Agent Skills index:
https://dondego.es/.well-known/agent-skills/index.json
Postman documentation:
https://documenter.getpostman.com/view/55094507/2sBXwjvZRZ
GitHub repository:
https://github.com/revanbcn/DondeGo-API
The repository also includes server-side examples for curl, Python, and Node:
https://github.com/revanbcn/DondeGo-API/tree/main/examples
And a ready-to-import Postman Collection:
https://github.com/revanbcn/DondeGo-API/tree/main/postman

Why not just publish OpenAPI?

OpenAPI is the most important artifact, but it is not the whole discovery story.
Different tools look for different signals:

developers want examples and a clear README
API clients want OpenAPI
Postman users want a collection
LLM-oriented tools can benefit from llms.txt
API discovery systems can use a linkset
agents need short, explicit usage guidance
partners need attribution and usage rules So the discovery layer is intentionally made of several small, stable surfaces instead of one giant documentation page. ## Verified endpoint families The current OpenAPI v0.1 spec is intentionally conservative. It documents only endpoint families we have verified and are ready to describe clearly: GET /locations/ GET /events/ GET /events/{id}/ GET /places/ GET /places/{id}/ GET /news/ GET /news/{id}/ GET /events-of-the-day/ GET /search/?q=...

We did not add endpoints just because they might exist somewhere.

We did not document parameters that still need verification.

We did not generate a huge speculative spec.

The goal of v0.1 is to describe what can be described accurately.

Quick example

The public API base is:

https://dondego.es/public-api/v1.4

List supported locations:

curl -s https://dondego.es/public-api/v1.4/locations/ | jq

List a few Barcelona event summaries:

curl -s "https://dondego.es/public-api/v1.4/events/?location=barcelona&page_size=3" | jq

Fetch event details:

curl -s "https://dondego.es/public-api/v1.4/events/{id}/?expand=place,images,dates,categories,tags,participants" | jq

More complete examples are available here:

https://github.com/revanbcn/DondeGo-API/tree/main/examples

The detail-first attribution rule

One important rule in the current API is event attribution.

Event list rows are useful for discovery, but they do not expose everything needed for safe public rendering. In particular, list rows do not expose the canonical DondeGo event page URL.

For public event rendering, the rule is:

event list -> fetch event detail -> use EventDetail.site_url as the visible DondeGo source link

This matters because any public website, app, newsletter, bot, AI assistant, or partner integration that displays DondeGo event descriptions or substantial DondeGo event data must include a visible direct link to the canonical DondeGo.es event page as the source.

That rule is repeated across the docs, examples, Postman collection, llms.txt, and API catalog.

It is not just a legal or SEO detail. It is part of making local data trustworthy.

If a user sees an event recommendation in an app or assistant, they should be able to click through to the original canonical page.

llms.txt

We publish:

https://dondego.es/llms.txt

This file is a short LLM-oriented index.

It points to the most important resources:

what DondeGo is
what the public API covers
where the OpenAPI spec lives
where the API Catalog lives
where examples live
what attribution rule must be followed
what is not supported yet

It does not magically make every model use the API.

But it gives AI systems and developer tools a clear, stable, crawlable reference.

API Catalog linkset

We also publish:

https://dondego.es/.well-known/api-catalog

This is served as:

application/linkset+json

It links to the core discovery resources:

OpenAPI
documentation
llms.txt
attribution policy
examples
version history
richer DondeGo discovery JSON

The richer DondeGo-specific JSON is available separately:

https://dondego.es/api-catalog.json

This split is intentional.

The .well-known/api-catalog route is a compact machine-readable linkset. The /api-catalog.json route carries richer DondeGo-specific context.

Documentation-only Agent Skills

We also publish a documentation-only Agent Skills index:

https://dondego.es/.well-known/agent-skills/index.json

The important part is “documentation-only”.

There are no scripts. No executable code. No hidden tool access. No permission escalation. No OAuth. No MCP transport.

The skill exists to teach an AI agent how to discover and correctly use the DondeGo public API documentation.

It explains the stable discovery URLs, verified endpoint families, attribution requirement, and detail-first event rendering rule.

What we intentionally do not advertise

This is probably the most important architectural decision in the whole package.

We do not advertise OAuth or OIDC support, because DondeGo does not currently run an OAuth issuer.

We do not publish OAuth Protected Resource Metadata, because the current public discovery package does not expose OAuth-protected scopes.

We do not claim to have an MCP server.

We do not claim to have WebMCP tools.

We do not document date filters or the limit parameter in OpenAPI v0.1, because those still need separate verification.

We do not publish browser-only examples yet, because CORS behavior should be handled deliberately, not assumed.

Accurate discovery metadata is more useful than fake “agent-ready” metadata.

If a site publishes machine-readable discovery files, those files should describe real capabilities.

Postman documentation

For developers who prefer Postman, we published public documentation:

https://documenter.getpostman.com/view/55094507/2sBXwjvZRZ

The repository also includes a ready-to-import Postman Collection v2.1:

https://github.com/revanbcn/DondeGo-API/tree/main/postman

The collection uses only public GET requests. It does not include environments, secrets, API keys, cookies, bearer tokens, or OAuth settings.

What this enables

This discovery layer is useful for several types of builders:

local newsletters that want to enrich issues with cultural events
city guides that need venues and event details
travel or lifestyle apps building a Barcelona or Madrid experience layer
AI assistants that need structured local data instead of guessing
developers who want to explore the API through OpenAPI or Postman
partners who need clear attribution rules before building on the data

The package is not a huge platform launch.

It is a foundation.

But I think this foundation matters.

Local media and cultural platforms should be easier to integrate with. They should publish machine-readable contracts. They should be understandable by AI-assisted tools. And they should be clear about attribution.

That is the direction we are taking with DondeGo.

Start here

GitHub repository:
https://github.com/revanbcn/DondeGo-API

Live OpenAPI:
https://dondego.es/openapi.json

Postman documentation:
https://documenter.getpostman.com/view/55094507/2sBXwjvZRZ

llms.txt:
https://dondego.es/llms.txt

API Catalog:
https://dondego.es/.well-known/api-catalog

If you are building a local guide, AI assistant, cultural newsletter, events app, map product, or city discovery experience for Barcelona or Madrid, I would be happy to talk.

Partner access and integration discussions:
bcn@dondego.es

First real use case of the DondeGo API: daily event picks for Barcelona and Madrid

Alexander Prokofiev — Mon, 04 May 2026 11:24:36 +0000

We have reached a small but important milestone for DondeGo API.

The first working use case is already live: we are using our API to power daily event selections for two local projects:

The idea is simple: every day, the system uses DondeGo data to select some of the best events happening today in Barcelona and Madrid.

Instead of manually searching across dozens of pages, calendars and sources, we can now use a structured local data layer with events, cities, dates, categories and editorial signals. This makes it much easier to build useful local discovery products.

Why this matters

A local event project usually needs three things:

Fresh event data
A way to filter it by city, date and category
Enough structure to build products on top of it

That is exactly what we are building with DondeGo API.

For our own use case, the API helps us answer questions like:

What is happening in Barcelona today?
What are the most interesting events in Madrid today?
Which events are good enough to recommend?
How can we turn local data into a useful daily feed?

This is still an early version, but it already shows the direction clearly.

DondeGo API is not just a technical experiment. It is becoming a practical content layer for local discovery.

Want to build something with events in Barcelona or Madrid?

If you are building a project about events, culture, local plans, maps, newsletters or city discovery in Barcelona or Madrid, we would be happy to share the data with you for free.

The only thing we ask is simple:
Please link back to DondeGo as the source.

That helps us keep building the project, improve the data and support independent local media.

Possible use cases

You can use DondeGo API to build:

local event newsletters
city guides
interactive maps
Telegram or WhatsApp bots
daily event feeds
cultural recommendation tools
“what to do today” pages
travel and expat guides
niche projects for families, concerts, exhibitions or free events

We are especially interested in small independent projects, local builders and media experiments.

Links

If you want to test the API or build something with local event data for Barcelona or Madrid, feel free to contact us.

We would love to see more projects using structured local data to make city life easier to discover.

We’re opening our events & local news API for Barcelona and Madrid. Free to use for side projects and products – the only requirement is a visible link back to the source.

Alexander Prokofiev — Fri, 27 Mar 2026 22:47:56 +0000

Alexander Prokofiev for API for events in Madrid and Barcelona

Mar 27

We built an API for events, places, and local news in Barcelona and Madrid

#api #barcelona #madrid #opendata

3 min read

We built an API for events, places, and local news in Barcelona and Madrid

Alexander Prokofiev — Fri, 27 Mar 2026 22:34:02 +0000

Building a local API for events, places, and news in Barcelona and Madrid GitHub

Most city products run into the same problem sooner or later.

You want to answer simple questions like:

What is happening today?
What is near these coordinates?
Which places belong to this category?
Which local news is still actually relevant?

But once you start building, local data is rarely clean enough. Events, places, and news often live in separate systems, use different filters, and do not map well to the way people actually explore a city.

That is one of the reasons we started opening up the data layer behind DondeGo.

DondeGo is a local media and city guide focused on Barcelona and Madrid. The editorial side is built around practical discovery: things to do, places to know, and local news that matters in city life. Recently, we have been turning more of that into an API that can be reused in real products.

What the API is trying to solve

The goal is not to build a huge generic directory.

The goal is to make local urban content easier to work with for developers, editorial teams, maps, newsletters, recommendation tools, and city-focused products.

Right now the API is centered around three main object types:

events
places
news

That makes it possible to support workflows like:

showing events happening today in Madrid
finding places within a radius from a point on the map
filtering objects by tags or categories
returning only current news items
building city guides or local recommendation layers

Recent changes in v0.1.0

We have just published v0.1.0, partly because I wanted the project to have a visible public milestone and partly because the API has become much more usable recently.

A few of the changes included in this version:

daily events now also include films
daily events can now return a title override
event and place categories now expose identifiers
filtering by tag slugs is supported via tags
news now supports an actual_only filter for current items
event date serialization now includes:
- start_date
- start_time
- end_date
- end_time
- is_continuous
- is_endless
- is_startless
- schedules
image serialization now includes authorship
it is now possible to fetch only films with free screenings
it is now possible to fetch only places with free events
is_free is now interpreted more strictly
categories for events and places can now be disabled in collection responses

None of this is especially flashy, but it moves the API closer to being something that is genuinely usable in production.

The kind of queries we care about

The API is most useful when it reflects how people actually navigate a city.

For example, a basic daily query:

GET /api/v1/events/?location=madrid&date=hoy

A proximity-based query:

GET /api/v1/events/?lat=40.4168&lon=-3.7038&radius=3000&date=hoy

And place discovery around a point:

GET /api/v1/places/?lat=41.3874&lon=2.1686&radius=2000

That may sound simple, but in practice this is the layer many local products need most.

Not “all possible city data”, but structured answers to questions like:

what can I do today?
what is nearby?
what is free?
what is still current?
what belongs to this area or category?

Why I find local APIs interesting

There are many great APIs in the world, but local discovery still feels oddly underserved.

A lot of the difficulty is not in storing records. It is in making the data useful in the context of a real city. Dates matter. Geography matters. Editorial freshness matters. Category structure matters. Free vs paid matters. Sometimes a simple “today” filter matters more than a complex taxonomy.

That is why I think local APIs are interesting. They sit somewhere between media, maps, structured data, and product design.

If you are building in this space

We are opening access gradually, but if you are working on a project around Barcelona or Madrid and need local events, places, or news, that is what we are building toward.

The public project is here, a bit more context lives there: DondeGo

I would also be curious how other people here would design this kind of API.

Would you prioritize geospatial search first, editorial freshness first, or category and tag structure first?