I'm writing this on a Thursday afternoon. Tomorrow morning I install a product I've spent six months building at a clinic in Los Angeles. The user is a board-certified behavior analyst named Kevin. He's the first paying user of BehaviorMate, the AI co-pilot we're building for clinicians who serve students with autism.
What I'm handing him tomorrow is materially different from what I'd have shipped in November. Not because we got better at building features. Because somewhere in those six months I became convinced that one thing matters more than every feature on a roadmap, and I'm now designing every Akasi product against it.
That thing is the gap between two kinds of software.
The first kind asks you to configure it. You pick preferences on day one, choose your genres, build a profile. The software's understanding of you is whatever you typed into a settings page when you signed up. It does not get sharper. It just gets older.
The second kind learns you. You don't tell Spotify in 2026 what you like the way you did in 2014. You listen, skip, save, share, and the system builds a model of you that's sharper than the one you'd build yourself. Your Discover Weekly knows things about your taste you couldn't articulate in a settings menu, and the longer you use it, the less interested you are in switching to a competitor that would treat you as a stranger.
That gap, between configured software and software that learns, is the most important product distinction of the next decade. We call this paradigm Symbiotic Software. We design every product at Akasi against it, and tomorrow morning is the first day a real user gets to test whether the bet works. This essay is the framework, why it's shippable now, and the architecture pattern that makes it work in practice, anchored in the BehaviorMate product itself.
The 1960 ancestor
The term "Symbiotic Software" is new. The vision behind it is sixty-five years old.
In March 1960, J.C.R. Licklider published "Man-Computer Symbiosis" in IRE Transactions on Human Factors in Electronics. He was at MIT Lincoln Lab, then BBN, soon to fund most of the foundational work in interactive computing through ARPA. His opening line is one of the most cited sentences in computer science history:
"Man-computer symbiosis is an expected development in cooperative interaction between men and electronic computers. It will involve very close coupling between the human and the electronic members of the partnership."
Licklider's frame was sharp. He wasn't imagining computers as faster calculators or better filing cabinets. He was describing a partnership where the human handled goals, judgment, and intuition, the machine handled formulation, retrieval, and pattern detection, and the loop between them ran fast enough that the boundary between the two stopped being legible. The cousin paper, Doug Engelbart's "Augmenting Human Intellect: A Conceptual Framework" (1962), made a parallel argument from a different angle: computers as intellectual prosthetics, not appliances.
What's striking, reading the 1960 paper today, is how right Licklider was about the philosophy and how wrong he was about the constraints. He worried about storing "billions of bits" costing "billions of dollars." That billion bits now fits on a USB stick that costs less than lunch. He estimated speech recognition of a 2,000-word vocabulary would take five years of research. Modern speech models recognize millions of words across a hundred languages with near-human accuracy. Time-sharing, his shared "thinking center" that fellow researchers would dial into, became the cloud. Desk-surface displays became iPads. The hardware ceiling he was fighting in 1960 turned out to be a floor everyone walked on by 2010.
The philosophy was the hard part. The infrastructure to actually run it was the part that took sixty-five years.
The vision didn't ship in any earlier wave. The reason is structural. Symbiosis requires bidirectional, real-time inference at scale. The machine has to read messy human signal, build a model of intent and preference, and adapt. For sixty years that capability either didn't exist or required a research lab and a Ph.D. to operate. Pattie Maes proposed interface agents in 1994, and Anthony Jameson catalogued user-modeling research in the Handbook of HCI for over a decade. The theory was rich. The shipping conditions were not.
The shipping conditions exist now. That's the whole story.
What changed
Three things made Licklider's vision economically viable in 2026 that weren't viable in 2016.
One: LLMs as inference engines. The hardest part of symbiosis was always turning unstructured behavioral signal into structured profile data. A BCBA dismisses one article and saves another. Did she dismiss it because the topic was wrong, the source was weak, the framing felt clinical when she wanted practical, or because she was busy? Until 2022, you needed a custom ML pipeline to even attempt that question. Today, you ship a Gemini Flash call with the right prompt and you get a useful answer for fractions of a cent.
Two: inference economics flipped. A relevance-scoring call against a clinical research article is roughly $0.00015 in Gemini Flash pricing. Run that against forty new articles per week per user, plus a weekly profile-synthesis pass, and you land at about $0.35 per user per month at scale. That is not a "we'll figure out unit economics later" number. That is a number you can put in a $25/mo Pro tier and feel good about gross margin.
Three: cloud-native data plumbing collapsed in cost. Firestore for per-user feeds, Cloudflare Workers for cron-driven pipelines, R2 for cold storage of audit logs. What used to require a Snowflake contract and a data engineer can now be run by a single founder for the price of a phone bill. The "enterprise data platform" has become a Saturday afternoon.
I'd read the Licklider paper twice over the years and filed it away as historical curiosity. The third time was the week we started rebuilding BehaviorMate's Insights surface. It hit differently. The vision was finally in shipping range. We are, right now, living inside the symbiotic future Licklider was describing in 1960. Most products haven't been built to admit it yet.
The framework: the Dual Learning Loop
Symbiotic Software, in product practice, is three layers stacked into one feedback loop.
Layer 1: Signal capture. Every meaningful interaction is logged with rich context. Not event: clicked, but event: insight_dismissed, category: research, source: JABA, confidence: 0.92, dwell_ms: 2300, view_count: 1, surface: editorial_row. If you ship a feature without thinking about what behavioral signal it produces, you are shipping a non-symbiotic feature. The signal you don't capture today is signal you can never recover. This is the most under-invested layer in the industry, and the cheapest one to add.
Layer 2: Profile inference. Periodically, a model takes the accumulated signal plus any explicit declarations the user made, and synthesizes a profile. For a BCBA, that profile might encode: "prefers VBMAPP over PEAK for autism assessments, dismisses purely academic JABA articles but saves applied case studies, never opens supervision-related content (already a BCBA-D), shows fatigue signals on Friday afternoons." This isn't recommendation-engine vector math. It's a structured document a human can read, audit, and challenge. Auditability is what keeps the system honest and what keeps Kevin from feeling like a stranger to his own product.
Layer 3: Adaptive surfaces. Every UI surface in the product reads the profile and adjusts. The news feed re-ranks. Default report templates change. The empty-state copy on the dashboard speaks differently to a Year-1 BCBA than to a clinical director. The CEU recommendations match the renewal calendar plus the topical interests inferred from saves. The product feels different on day 90 than it did on day 1, in ways the user didn't have to ask for.
The loop is what compounds. The user invests effort, the software responds with sharper relevance, the user invests more because relevance is now worth their time, the software gets sharper still. Andy Matuschak's "How can we develop transformative tools for thought?" describes this same shape from the learning-tools angle. The best tools don't just deliver content, they remodel themselves around the learner. Gordon Pask's Conversation Theory, published in 1976 out of cybernetics, got to roughly the same place a different way. None of this is new philosophy. What's new is that you can finally implement it in a weekend.
A worked example: the BCBA professional growth co-pilot
BehaviorMate is the product where we first formalized this framework. The user is a board-certified behavior analyst, a clinician serving caseloads of students with autism and developmental disabilities, drowning in administrative and clerical work. The Insights surface inside BehaviorMate started as a static news widget. We're rebuilding it as a per-BCBA professional growth co-pilot. Here is the actual architecture.
Sources. Eight to ten clinical and professional feeds: Journal of Applied Behavior Analysis, Behavior Analysis in Practice, the BACB blog, CalABA, Behavioral Health Tech, plus the PubMed E-utilities API for real DOIs. Admin can add or remove sources from a curation panel.
Pipeline. A Cloudflare Worker on a 6am daily cron pulls feeds, dedupes by URL hash, keeps a rolling seven-day window. For each new article, it calls Vertex Gemini Flash (BAA-covered, so HIPAA-aligned) to produce a structured digest: {summary, key_takeaway, relevance_score, why_it_matters}. The relevance score is computed against a tokenized representation of the BCBA's caseload, deterministic features only, never PHI. A nine-year-old student with ASD Level 2 whose function is escape becomes {age: 9, dx: ASD_L2, fn: escape} at the LLM boundary. No names, no initials, no identifiers cross.
Storage. Per-tenant feeds in Firestore at bm_insights/{tenantId}/feed/{articleId}, with a 30-day TTL. The Insights UI reads from the store and renders cards sorted by relevance, each with a bolded "Why this matters to your caseload" pull quote that anchors the article to the specific clinical patterns the BCBA actually works with.
Signal capture under the hood. Yesterday I added nine new event types to the codebase: news_article_opened with item ID, source, category, and surface (featured hero versus editorial row); news_saved and news_unsaved; insight_dismissed with confidence and surface; insights_filter_changed from one active filter to another; caseload_filter_changed across stage, district, and setting dimensions; and assessment_battery_selected. The inference engine that uses any of this doesn't ship for another sixty days. That doesn't matter. The signal you don't capture today is signal you can never recover, and Kevin starts using the app tomorrow.
Profile synthesis. Once a week, a second worker takes ninety days of the BCBA's audit events plus her caseload taxonomy and asks Gemini Flash to write a structured profile. Preferred assessment instruments. Article categories that earn saves versus the ones that earn dismissals. Inferred career stage and trajectory. Topics under-served by current saves where she'd probably want exposure. The profile is a JSON document a human can read.
The cost math. Forty article digests a week at $0.00015 each is $0.024/week per BCBA. A weekly profile synthesis at roughly $0.05. Round up generously and you land at ~$0.35/mo per BCBA. At a hundred BCBAs, the entire personalized-research-feed feature costs Akasi $35/mo to operate. It justifies a $25/mo Pro tier upcharge with 90%+ gross margin. The economics are not the bottleneck. They never were going to be, once Flash-class models existed.
What surfaces look like. A BCBA opens her dashboard Monday morning. Three articles are surfaced. Each card shows the title, source, a one-line summary, and a bold pull quote: "Why this matters to your caseload: 60% of your students have escape-maintained behaviors, and this paper proposes a faster FBA protocol for that function." She saves one, dismisses one, opens the third. The pipeline writes those events. By Thursday, the next batch already weighs that signal. By month three, the feed is unrecognizable from what a generic BCBA would see. By month nine, it is a professional growth co-pilot, not a news widget.
What's hard about this
The framework is not a free lunch. Four failure modes show up reliably, and we plan for each one before we ship.
Cold start. A new BCBA with three students and no usage history can't be personalized. The system has nothing to infer from. Mitigation: a fallback ranking model based on professional taxonomy alone (credential level, caseload size, declared specialties), and ungated top-quality content until at least a minimum signal threshold is reached. Symbiotic value compounds, but you owe the user a non-embarrassing day-one experience.
Privacy and HIPAA. Behavioral signal about the BCBA's professional patterns is not PHI. Behavioral signal about her students absolutely is, and getting that boundary wrong once is enough to kill the product. The mitigation is to tokenize at the LLM boundary and never before. The model receives clinical features (age, function, diagnosis level), never names, never initials, never dates of birth. The audit log is locked down to the same standard. We treat this constraint as load-bearing in every architectural decision, not as a compliance afterthought.
Filter bubble. Over-personalization narrows what the user sees to what they already know they want, which is exactly the wrong outcome for a clinician trying to grow their practice. A BCBA who only reads escape-function articles never encounters the joint-attention literature she'd benefit from. We reserve roughly twenty percent of every surfaced feed as explicit "exploration slots," intentionally outside the inferred profile, surfaced with an honest justification: "you haven't seen this category recently, here's what's new in it." The profile influences the feed; it doesn't dictate it.
Profile drift. A Year-2 BCBA studying toward BCBA-D credentialing is a different professional than a Year-5 clinical supervisor running a team of six RBTs. If the profile only ever sees old signal, it stays old, and the product slowly gets less useful as the user's career evolves. Time-decay weighting in the synthesis pass handles part of this. The other part is giving the user an explicit "this doesn't feel like me anymore" reset they can trigger when their work changes shape. The profile is theirs to correct, not just ours to compute.
The compounding moat
The competitive logic of Symbiotic Software is the part most teams miss. The moat is not the model. The moat is the longitudinal behavior data joined to the domain taxonomy.
A competitor launching a BCBA tool tomorrow can clone the UI in a weekend. They can call the same Gemini Flash API. They cannot replicate ninety days of one specific BCBA's saves, dismisses, dwell times, and filter shifts. They can't replicate the cross-product compounding either: a BCBA's assessment-tool preferences captured in the assessment module sharpen the news feed in the insights module, sharpen the CEU recommendations, sharpen the report templates. Cross-feature signal compounding is the moat Reid Hoffman and Chris Yeh point at in Blitzscaling when they talk about products that get sharper with scale.
This shape of value gives you the right shape of revenue. Subscription pricing is the correct business model when value compounds with tenure, because churn cost goes up with every additional month. The customer leaves their profile behind. The user owns their data outright (we honor export rights, always), but the inference system that produced their profile, and the cross-product signal graph that made it sharper than any competitor's, stays with the product.
How we apply this at Akasi
BehaviorMate is the most fully expressed version of this approach in our portfolio, but the pattern shows up everywhere we're building right now.
One of our active builds is a mortgage lead-generation platform serving a niche borrower segment that traditional banks misroute or reject outright. The version most people would have shipped is a static form that emails leads to a fixed list of partner lenders. The version we're shipping captures the back-and-forth between every borrower and every lender, learns which lenders close which borrower profiles, and gradually shifts routing toward the matches that actually fund. After ninety days the platform is meaningfully better at picking lenders than the founder is. After a year, the routing logic is the moat.
Another is a vehicle-procurement agent that runs the dealer-side of car buying for the buyer. We wrote about an early version of this. The interesting layer is the one we didn't write about: every counter, every concession, every dealer's response time and bargaining pattern is captured. By the third buyer the system runs through, it knows which dealers in a given region give up margin first, which ones lie about inventory, which ones honor out-of-state pricing. The buyer is never told this directly. The agent just gets quietly better at knowing where to push.
A personal media recommendation extension we're building learns viewing taste from in-the-flow behavior — what gets paused at minute four, what gets re-watched, what gets skipped after the trailer — and synthesizes a profile that beats every "tell us your favorite genres" onboarding flow on the planet. Same architecture, completely different domain.
What unifies these is not the feature set. It's the four questions every Akasi product gets evaluated against before it ships.
What signal is this feature capturing, and is the context rich enough to be useful in ninety days? How does the user profile change as a result of this signal? How does another feature elsewhere in the app benefit from this signal, today or eventually? And if this feature can't contribute to a profile, should it exist at all in a symbiotic product?
That last question is the hardest one. It eliminates a lot of features that look reasonable on a roadmap but produce no learnable signal. A static FAQ widget. A one-shot tutorial. A "rate this experience" thumbs-up that nobody clicks. They might still belong in the product, but they're not pulling their weight in the symbiotic system, and we treat them accordingly.
Where this is going
Five years from now, "Symbiotic Software" stops being a term. It becomes the default, then disappears as a category the way every transformative substrate eventually does.
Nobody calls a company "an internet company" anymore. Once a substrate becomes universal, the label that named it becomes redundant, then quaint. "AI-powered" in 2030 will sound the way "electrically powered" sounds today, and the products that have to advertise it will be the ones still figuring out how to use it.
The window to define this pattern is the next twelve months. Three years out there's no positioning advantage in saying "our product learns you," because every product will. The firms that internalize the pattern now, the design vocabulary, the data discipline, the privacy posture, the cross-feature signal graph, get the unfair head start when symbiosis becomes table stakes. Everyone else spends those years retrofitting static products with AI features bolted on, wondering why retention isn't moving.
The deeper shift is this. Software has been static for sixty years. Every interaction surface you've ever used was a deterministic state machine waiting for input. Same pixels for every user, same flow for every session, personalization handled by a settings page you configured once. Adaptation was something humans did to software. It was never reciprocal.
That ends. The substrate is becoming bidirectional for the first time since the field invented itself. Software that watches, infers, adapts, asks better questions next time. The first conversation I had about BehaviorMate, six months ago, was about which features to build. The fifth was about which signals to capture. That shift, from features to signals, is the whole change.
Most founder conversations we have at Akasi still open with "where can we add an AI feature." It's the wrong question, and the right one is harder to answer: what does this product look like if it learns my customer for three years. The founder who can answer that one is building a different company, in a different shape, with a different revenue curve. Those are the founders we want to work with.
The bet behind Akasi is not that AI is a useful capability to bolt on. It's that mutual adaptation is the substrate, and that companies which internalize this in 2026 will be unrecognizable from companies which were still writing static interfaces in 2030.
If you're building a product and you've been wondering whether there's a way to make it feel like it gets sharper the longer someone uses it, there is. The framework above is what we apply at Akasi. The infrastructure to ship it costs less than your team's coffee budget. Licklider's 1960 vision is finally a shipping target, not a research paper, and the firms that take it seriously this year will look very different from the ones still adding chatbot widgets in 2027. Grab a free systems audit and we'll map your product's signals together.