Landfall finds
the thing
How an agent found the current truth across texts, email, chat, PDFs, public records, and stale notes.
The facts were not in one place
The client relationship had the kind of facts that never sit politely in one system. A founder had texted Daniel. A deck lived as a PDF. An outside engineer was introduced by email. A private chat room had internal notes. The rolodex was stale. The grown-up answer was sync jobs and schemas. That was too much for a live relationship. Landfall gave the agent one bounded job: find what changed, save the evidence, update the durable notes, and stop before sending anything.
The problem
The client relationship started like real work starts: outside a clean database. The facts were scattered across the places people actually use when work is moving quickly. A founder had texted Daniel. She sent a deck as a PDF. Daniel sent a build guide by email. A private chat room held internal notes. An outside engineer was introduced later by email. Public records corroborated some background facts. Local folders had partial state. The rolodex was already stale.
The data was not one system
An agent could search each surface manually once. That still leaves the next agent with the same bad afternoon: rediscover the same sources, wonder which ones matter, and make the same boundary decisions. Worse, it might summarize stale state and skip the one current email Daniel actually needed to answer.
The failure mode
The problem was not that the facts were scattered. The problem was that the agent had no map. Without one, it did not know which sources mattered, what counted as fresh, what could be updated, or where it had to stop.
An infrastructure-first answer would normalize every source before useful work happens. The messy sources win there. One deck attachment becomes an attachment parser. One text thread becomes a messaging export problem. One missing profile URL becomes a public-search workflow. One email Daniel may need to answer becomes a browser-link requirement. The tail keeps growing.
Classic problems in this one relationship
The notes implied the founder was still deciding. Fresh email showed the outside-engineer intro path had already moved.
The deck was not in a CRM or data room. It was a PDF from the message trail and had to become explicit evidence.
A summary was not enough. Daniel needed browser links back to the email thread so he could respond himself.
The founder, advisor, and outside engineer each needed different kinds of confirmation across private messages, public web, and local rolodex state.
The approach
Landfall treated the relationship as a search for the current truth, not a miniature data-platform project. The agent built a YAML contract that named the sources, questions, write targets, and stop conditions. The working metaphor was Hungry Hungry Hippos for data, but the mechanism was serious: gather the messy facts, write down what changed, and stop before a human-only action.
What Landfall changed
The goal was not clean data. The goal was a repeatable intake path.
name: relationship-intel-landfall
size: focused
purpose: Refresh the client relationship picture.
sources:
email:
commands:
- "private-email search 'client project' --limit 20 --json"
- "private-email search 'outside engineer intro' --limit 20 --json"
connector_actions:
- "email_read_thread id=example-thread-id id_type=thread max_messages=20"
chat:
channel_name: "private client room"
channel_id: "example-channel-id"
files:
paths:
- "README.md"
- "/Users/.../engagements/client/README.md"
questions:
- id: latest_direct_signal
prompt: "What is the latest direct signal from the founder or advisor?"
- id: email_review_links
prompt: "Which email links let Daniel open messages directly?"
write_targets:
summaries:
- "notes/landfall-YYYY-MM-DD-relationship-intel.md"
stop_conditions:
- "Do not send outbound email without explicit approval."
- "Do not expose the client externally before consent."The CLI turned that local contract into an execution packet. It did not send email, decide legal posture, or pretend the folder was a database. It told the agent where to look, what to save, what to update, and what to leave alone.
landfall doctor
landfall brief relationship-intel
landfall run relationship-intel --write-report
# output includes:
# - source commands
# - connector actions
# - questions to answer
# - write targets
# - required sections
# - human-only stop conditions
# - .landfall/runs/<timestamp>-relationship-intel-landfall.jsonWhat it learned for next time
The evidence
The landfall refreshed the sources and changed the operating picture. The stale state said the founder was still deciding whether to proceed. The fresh state showed the first outside-engineer path was already active: Daniel had made the introduction, the engineer replied positively, the founder sent the deck, and the open action was confirming a Friday call.
How messy sources became operating state
- Engagement notes said the founder was still consulting an advisor.
- The advisor's rolodex record lacked email, profile, and public role evidence.
- The outside-engineer intro thread was not a required source.
- The agent could summarize email state without giving Daniel direct message links.
- The local client folder could be mistaken for authoritative source-controlled state.
- Engagement status changed to engineer-intro active.
- The advisor's public role and evidence limits were recorded.
- The outside-engineer email thread became part of the landfall contract.
- Email-review links became a required output section.
- The local folder's provenance limits were recorded explicitly.
The important part is that every source became named, bounded, and repeatable. The next agent can run the import with a better contract than the previous one had.
The result
Landfall became both the tool and the proof of the pattern. As a tool, it helps agents find the current truth in messy sources. As a case study, it shows that useful agent work can begin with a small contract before it becomes infrastructure.
That distinction matters. A data platform is excellent when the domain repeats at scale. But many high-value agent tasks begin before the schema exists: one client, one house sale, one vendor issue, one relationship, one decision. AI creates more of these moments because it makes more ambitious work cheap enough to attempt. Landfall lets the agent capture the live context now, update the durable surface now, and leave behind a run packet so the next agent is less blind.
What this argues
You do not always need to centralize data before agents can use it. You need to train the agent how to import messy data for the current job: what to look for, where to look, what freshness means, what output must be durable, and which actions remain human-only.
The next step is productizing the ritual: schema validation, landfall init, richer completion records, and a public package. But the core pattern already works: bounded intake, explicit stops, durable writeback, and a trail for the next arrival. Every run should leave the next run with fewer unknowns, better source hints, clearer output requirements, and sharper stop conditions.