AI Knowledge & Systems Architect — company migration, retrieval layer, verified automation

We started as a luxury private client styling business five years ago and we are winding that company down on December 31 to grow the consumer software business we have been building: an AI-native fashion marketplace, new Delaware C-corp, new domain, new everything. Five years of operating history lives in the old company, and we have until December 31 to get it into the new one correctly. Full detail is attached. The short version: WHAT WE NEED, IN PRIORITY ORDER One. Get the migration right. Everything the new company needs arrives intact and searchable. Everything that should stay behind stays behind. Both failures are expensive and mostly unrecoverable. Two. Give us one machine interface over our content. Our AI agents cannot reliably retrieve our own documents, and our automations cannot prove they wrote what they claim. Our CEO designed and built the current stack herself. The applications work individually; the layer across them does not. She spent two weeks rebuilding one nightly routine that still does not run, and she does not have time to become a full-time agent orchestrator. THE PROBLEM, HONESTLY No common machine interface. Reach varies by agent surface, permissions are inconsistent, writes are unverified. Shared-drive retrieval through AI connectors is unreliable and spreadsheet content does not index. Markdown, which is most of what our AI tools produce, does not open in our shared drive at all. One agent reads our private code repositories, another has no repository access, a third holds no credential. Automations that lie. One scheduled job ran for two weeks reporting success while writing nothing. It stalled mid-run and exited cleanly. Everything downstream kept consuming a report that had quietly stopped being true. An incoherent corpus. Our decision records contain superseded entries and our project context goes stale. Excellent retrieval over a contradictory corpus produces well-cited incoherence, which is worse than no retrieval because it arrives with sources attached. Finding documents is not the whole job. WHAT WE RUN Google Workspace, Linear, Airtable, Slack, GitHub, Fireflies, Claude, Attio, Apollo, HubSpot, Ramp, QuickBooks, 1Password, DocuSign, Netlify, and a Slack-based agent that produces genuinely good daily executive briefings. We are not attached to any of it, but would need a very good reason to migrate another tool. We have deliberately left our own vendor research out of this posting because we want your read, not ours reflected back. PHASE ONE: ASSESSMENT AND PROOF OF CONCEPT Hourly against a cap we agree up front, roughly two to three weeks. Read-only access plus a segregated sample corpus. What we are buying is a scored comparison of configured products, a working proof of concept rather than a diagram, a retrieval benchmark with measured results, a verified write pattern demonstrated in one real workflow, and a migration sequence. No migration starts until the benchmark passes. Phase two is the build, hourly, commissioned separately. After that we want you available as the product ships and workflows change. Not a full-time operator. HOW WE WORK Small team, Los Angeles, Pacific time. Mostly async and written. One live check-in a week, thirty minutes, more only if something is genuinely stuck. Everything else in a shared Slack channel. Nothing scheduled before 8:30am or after 5:30pm Pacific. Written updates twice a week: what you did, what you found, what you decided, what you need from us. Short is fine. We would rather have four honest sentences than a status deck. We will give you direct answers and fast decisions. In return, tell us when we are wrong, and flag problems when you find them rather than when they become unavoidable. DOCUMENTATION IS A DELIVERABLE This matters more here than in most engagements, because the problem we are hiring you to solve is that our own knowledge is scattered and unreachable. If your work lives in your head or in Slack threads, you have recreated the problem you were hired to fix. Every decision written down with the reasoning, not just the outcome. What you tried, what you rejected, and why. TO APPLY Answer these three: One. Our agents each reach a different subset of our stack and none of them reads our documents reliably. What would you actually do, and what would you test first? Two. Tell us about a scheduled job you built that failed silently. How did you find out, and what changed structurally so it could not happen again? Three. What is one thing you would refuse to automate, and why? We read every answer. We care about judgment far more than hours.