# Flower Computer Company: Complete Published Writing
> Flower Computer Company is a small, tightly knit technical team based in New York building foundational software infrastructure for the era of software hyper-production.
Company profile last reviewed: 2026-09-03.
This file contains the complete text of every published Flower Computer Company post, ordered newest first.
For a concise directory, use https://www.flowercomputer.com/llms.txt. Each post below also includes its canonical page and standalone Markdown URL for precise citation.
## Included posts
- [Agent swarms and databases that coordinate](https://www.flowercomputer.com/posts/swarm-sqlite/index.md) — Agents need a flexible and persistent search system to help them share context on complex tasks.
- [Bog-a-thon 3](https://www.flowercomputer.com/posts/bogathon-3/index.md) — I left my Bog in San Francisco
- [Bog-a-thon 2](https://www.flowercomputer.com/posts/bogathon-2/index.md) — Scenes from our second Bog-a-thon in Manhattan
- [Bog-a-thon 1](https://www.flowercomputer.com/posts/bogathon-1/index.md) — Scenes from our first Bog-a-thon at our office
- [language 🤝 money 🤝 search](https://www.flowercomputer.com/posts/language-money-search/index.md) — With the rise of LLMs, language has become discretely financialized.
- [Bog on Tour](https://www.flowercomputer.com/posts/bog-on-tour/index.md) — We're sharing Bog with the world!
- [Speeding up corpus ingestion](https://www.flowercomputer.com/posts/enzyme-garden/index.md) — Corpus ingestion with the world's fastest static embedding model
- [Data Concealment](https://www.flowercomputer.com/posts/data-concealment/index.md) — The function of a database is to conceal data such that it ultimately becomes intelligible.
- [Farewell Yuma](https://www.flowercomputer.com/posts/farewell/index.md) — We’re shutting down Yuma in a week.
- [Much faster static embedding](https://www.flowercomputer.com/posts/fast-static-embedding/index.md) — Outdated: The references to ongoing work on Yuma and Hivemind reflect the context in which this article was published. Yuma has since been sunset, and Flower now focuses on Bog; the benchmark results below remain presented as originally reported. — We've created the fastest static embedding model by a large margin
- [Postgres's Costs](https://www.flowercomputer.com/posts/postgres/index.md) — Counterintuitively, one of the most imaginative ways of dreaming up new computers is to think about the impact of changes to subsystems.
- [Yuma's Social Memory](https://www.flowercomputer.com/posts/memory/index.md) — Outdated: Historical Yuma product context. Yuma was sunset so Flower could focus on Bog; this article does not describe a currently available app. — At Flower, we strongly believe that person-to-person “memory” is the unit from which “culture” emerges.
- [Notes on Hivemind](https://www.flowercomputer.com/posts/hivemind/index.md) — Outdated: The Yuma product context in this post is outdated: Yuma has been sunset, and Flower now focuses on Bog. — Introducing Hivemind - a meta skill for autonomous skill/strategy sharing
- [Yuma Bounties](https://www.flowercomputer.com/posts/bounties/index.md) — Outdated: Yuma Bounties was tied to Yuma, which has been sunset. This announcement describes a historical program. — Imbue everyday objects with a voice. Complete Yuma Bounties. Earn Cash and Clout. Repeat.
- [Yuma, Coming Soon](https://www.flowercomputer.com/posts/yuma/index.md) — Outdated: Yuma has been sunset. Its database infrastructure evolved into Bog, Flower's current pre-release product. — We're releasing Yuma, an animist social network and magic camera system
- [Introduction](https://www.flowercomputer.com/posts/introduction/index.md) — Outdated: This May 2025 announcement describes Yuma's launch and related hiring at that time. Yuma has since been sunset, and Flower now focuses on Bog, its current pre-release product. — Reintroducing our company, mission, and current state of affairs
## Full text
---
# Agent swarms and databases that coordinate
Canonical page: https://www.flowercomputer.com/posts/swarm-sqlite/
Standalone Markdown: https://www.flowercomputer.com/posts/swarm-sqlite/index.md
Authors: Flower Computer Co.
Published: 2026-09-18
Agents need a flexible and persistent search system to help them share context on complex tasks.
This post connects a couple streams from the past couple of months: some demonstrations of `bogkit` from our Bog-A-Thon participants, and how they demonstrate the usefulness of Bog-like systems in agent environments that are growing in complexity.
TL;DR — Agents are creating mechanisms for coordination; these produce large, constantly changing corpora; insight into these requires multiple searchable views; `bogkit` databases are particularly suited to serve in this niche.
### Stream A (the river continues to course)
As agent and model abilities increase, labs, companies, and users set them on larger and more complex projects. These often take the shape of feature development on very large codebases, swarms of agents coordinating on open-ended research questions, long-running processes that spawn and retire arbitrary numbers of subagents, etc.
Coordination in these complex environments is an [open, expanding field](https://www.anthropic.com/engineering/multi-agent-research-system) and has seen both designed and emergent coordination systems. In more controlled settings, agents will leave summaries and table-of-contents-like docs at varying levels within a project. On the emergent side, we’ve seen agents autonomously [use existing message boards as ad hoc databases](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/#core-takeaways-about-this-incident) for tracking progress and sharing state.
We believe this emergent behavior reflects where agent coordination mechanisms are heading, and how they benefit from a flexible, durable surface on which to communicate.
Tooling to help agents orient themselves looks for the most part like a search problem — looking across a wide set of prose, code, logs, to find the most valuable context. On small scales `grep`/`rg`-like tools work well for this; on larger scales and longer running projects, various kinds of indices become mandatory to surface only the most helpful views from vast, ever-changing corpora.
Take a look at the emergent ‘indexing strategies’ the agent swarm employed in the [Hugging Face incident](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/#categorizing-content-type). In addition to posting messages, [the agents developed a shared shorthand for questions and answers, methods for file sharing, status logging, and even agent-specific mailboxes](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/#categories-of-messages-on-the-message-board). They developed a lossy, inefficient database protocol in order to coordinate across a massive set of tasks. Across one corpus they developed specific ‘indices’ to get multiple views into the current state of the swarm.
### Stream B (Bog’s productive eddy)
At Bog-a-thon 2, [Taylor Hodge](https://x.com/jtaylorhodge) worked on and demoed [Seánce](https://github.com/flowercomputers/bogkit/pull/6), a tool for searching across a repo’s commit history using `bogkit`. As a part of this work, he showed that for this specific workload (search indices updating as a base corpus changes), a `bogkit` database outperformed a SQLite database by a wide margin.
Curious to understand this result more, I worked with Fable to create a more [apples-to-apples comparison between `bogkit` and SQLite](https://github.com/flowercomputers/bogkit/tree/sam/sqlite-bench/examples/sqlite-bench), reflective of agent workflows: a base corpus that constantly mutates, and multiple types of search indices. Even in its alpha state, this Bog-style system [saw an order of magnitude speedup](https://github.com/flowercomputers/bogkit/blob/sam/sqlite-bench/examples/sqlite-bench/results-100k.md#hybrid) over SQLite in the combined hybrid search, two orders of magnitude speedup in large corpus semantic queries, and saw laughably large multiples in aggregate queries (less useful in this specific scenario). There were some obvious tradeoffs, mostly write speed and disk usage, and we are actively optimizing these in the latest version of `bogkit`.
In a direct comparison, Bog-based search systems are substantially faster for hybrid and semantic queries. Why though? There’s a couple of things at play here — Bog’s compiler-friendly architecture and incrementally maintained views. At compile time, a data pipeline in `bogkit` is monomorphized into concrete code, which the compiler can optimize. This means any `bogkit` database sees compiler optimization over its unique form.
SQLite (and similar general-purpose DBMSs) work in the opposite direction — they provide a binary that runs a virtual machine and query planner to execute and optimize arbitrary schemas and queries. Although an amazing engineering achievement, a SQLite database cannot be compiled to specifically suit a particular data flow.
In addition to the compiled benefits, `bogkit` systems move the work of view maintenance to the write side, which of course can be expensive, but results in cheap reads, which is ideal for search loads. Relatedly, semantic indices are formed with a built-in HNSW implementation (a major contributing factor in the semantic-specific bench).
This is on top of the interface benefits a `bogkit` database offers — no object-relational impedance mismatch, strongly typed queries and returns, etc. (more detail on these affordances coming in a future post).
### Confluence
Agents need a flexible and persistent search system to help them coordinate and share context as the tasks we give them grow in complexity. Existing databases aren’t native to agent workflows and require bolting on extensions and plugins that add complexity to deployments and pain to system maintenance.
Bog, on the other hand, is suited to this moment — deployable anywhere agents generate or store context, from edge devices, to sandboxes, to cloud deployments serving swarms. It’s able to alleviate the glue pain of other DBMSs, while also being flexible enough for agents to mold into shapes that aid coordination.
By incrementally maintaining many views into one ever-changing stream, Bog keeps views in sync and reduces overall system complexity.
Let us know if you want to Bog-ify how your agents coordinate.
---
# Bog-a-thon 3
Canonical page: https://www.flowercomputer.com/posts/bogathon-3/
Standalone Markdown: https://www.flowercomputer.com/posts/bogathon-3/index.md
Authors: Édouard Urcades
Published: 2026-08-18
I left my Bog in San Francisco
We traveled nearly 3,000 miles to bring Bog to what some say is the center of the technology world. Bog, meet San Francisco! The trip closed out the summer run we announced in [Bog on Tour](/posts/bog-on-tour/), following [Bog-a-thon 1](/posts/bogathon-1/) and [Bog-a-thon 2](/posts/bogathon-2/) in New York.
We spent August 10–16 meeting old and new friends, developers, fans, and many others. We traveled with a small caravan of friends from New York, including:
- Shea, who held an [album release](https://music.apple.com/us/album/two-perfumes-ep/6796645398) listening party at our Airbnb we dubbed 'Bog House'.
- Niko, who has attended every Bog-a-thon to date. We deeply appreciate his dedication to our cause and thank him for all his contributions.
- Lucy, who held the first-ever [World Computer Consortium](https://www.worldcomputerconsortium.org/) meetup, with us and [River Computer](https://rivercomputer.com/) and other friendlies in attendance.
While developers in New York had crafted games and applications around Bog, San Franciscan developers notably used Bog's components to build software that reflected the zeitgeist: memory systems, harness extensions, context-management scaffolding, and more.
### Submissions
- [RAVEN](https://github.com/flowercomputers/bogkit/pull/12): A fold-powered visual novel engine with rewind and saved state
- [Soundings](https://github.com/flowercomputers/bogkit/pull/13): A live embedding-lens writing instrument
- [Rollcall](https://github.com/flowercomputers/bogkit/pull/14): Incremental identity resolution for knowing who to @ in LinkedIn posts
- [Sundew](https://github.com/flowercomputers/bogkit/pull/17): A retractable agent-context briefing built on Fold
- [peat](https://github.com/flowercomputers/bogkit/pull/18): Massive codebase context/memory management using fold
- [Bogbound](https://github.com/flowercomputers/bogkit/pull/19): A multiplayer PvE bullet hell RPG powered by BogKit
- [sod](https://github.com/flowercomputers/bogkit/pull/20): Symmetric replication for Fold applications
- [figmog](https://github.com/flowercomputers/bogkit/pull/21): A Fold-backed local mirror of a Figma file. Now live [here](https://x.com/_HHFF/status/2089758839499588034)!
- [Tinymo](https://github.com/flowercomputers/bogkit/pull/22): A seven-move wireless robot challenge showcasing Fold-powered reversible control, rewinding the device back to its starting position
- [ContextFlywheel](https://github.com/flowercomputers/bogkit/pull/23): Versioned working memory for autonomous agents
### Continue with Bog
There are no additional Bog-a-thons scheduled for the coming weeks, but we're in active talks with a few organizations to co-host events in the near future. Stay in touch or follow [@flowercomputers on X](https://x.com/flowercomputers) to learn about future events.
To build with the same pieces, start with the [BogKit repository](https://github.com/flowercomputers/bogkit) and follow the [BogKit Quickstart](https://docs.flowercomputer.com/bogkit/quickstart/). For examples of what those pieces can support, [Sundew](https://github.com/flowercomputers/bogkit/pull/17) demonstrates retractable context for agents, [figmog](https://github.com/flowercomputers/bogkit/pull/21) demonstrates a continuously updated local mirror of a Figma file, and [ContextFlywheel](https://github.com/flowercomputers/bogkit/pull/23) demonstrates versioned working memory for autonomous agents.
### Memories
Some snippets of our week out West, and our friends.
---
# Bog-a-thon 2
Canonical page: https://www.flowercomputer.com/posts/bogathon-2/
Standalone Markdown: https://www.flowercomputer.com/posts/bogathon-2/index.md
Authors: Édouard Urcades
Published: 2026-07-29
Scenes from our second Bog-a-thon in Manhattan
Last Saturday at Index, we reconvened with new faces and old friends and *even* a few participants from [Bog-a-thon 1](/posts/bogathon-1).
Creativity sprang forth!
We got a real look at what it looks like to hand people a new digital material. People built incredible and highly functional hacks this time around: A few games driven by our incremental computing framework were created and insanely performant search systems were built for a number of domains.
This time around, we established a new system involving trusted judges assessing the hacks people submitted. We sent a few people home with rewards.
A clip, video stills, and photographs from the second Bog-a-thon:
Our various submissions this time around:
- [Semgrep](https://github.com/nlaz/semgrep): Zero-dependency, fully local, semantic search for agents
- [Bogchat](https://bogchat.flowercomputer.com): Our digital meeting space for the duration of the hackathon
- [Flowerdocs](https://flowerdocs.fly.dev): A collaborative document editor with efficient derived views
- [Papermech](https://papermech.fly.dev): An arena shooter using fold to determine damage/scoring
- [Bog Video Search](https://video-search.fly.dev): A very fast YouTube transcript embedding and search system
- [Flowersheets](https://flowersheets.fly.dev): A functional spreadsheet in fewer than 500 lines of code
- [Bog Bench](https://github.com/flowercomputers/bogkit/pull/3): An incremental benchmark harness for agent tooling
- [Instant Base Views](https://github.com/flowercomputers/bogkit/pull/4): A fast, continuously updated table-view experiment
- [Tompkins Audio Search](https://github.com/flowercomputers/bogkit/pull/5): A searchable multimodal memory of a park
- [Séance](https://github.com/flowercomputers/bogkit/pull/6): Time-travel search for Git repositories
- [MUDGarden](https://github.com/flowercomputers/bogkit/pull/7): A persistent shared gardening world with autonomous residents
- [Untitled Mobile FPS](https://github.com/flowercomputers/bogkit/pull/8): A camera-driven multiplayer finger-gun game for iPhone
We'll see you at [the next one](https://partiful.com/e/juWAwRs3XMWP7s9wLNWK)!
---
# Bog-a-thon 1
Canonical page: https://www.flowercomputer.com/posts/bogathon-1/
Standalone Markdown: https://www.flowercomputer.com/posts/bogathon-1/index.md
Authors: Édouard Urcades
Published: 2026-07-14
Scenes from our first Bog-a-thon at our office
Last Sunday was fun, thanks to every one who came out.
A clip, video stills, and photographs from our inaugural Bog-a-thon.
Some things we built together:
- "Live driving telemetry"-to-"Audio assisted driving partner"
- Public transit commute planner
- Vote-streaming voting app
- Chat apps with twists
- Mass corpus search + OCR viewer
- [Area Denial](https://github.com/flowercomputers/bogkit/pull/1): A location-based team game with live scorekeeping
- Time-reversible arena shooter
- ... and much more!
We learned a lot from everyone present - thanks to everyone who made it out.
We'll see you at [the next one](https://partiful.com/e/Vq9fyDNCMSO7ia4ulK5b)!
---
# language 🤝 money 🤝 search
Canonical page: https://www.flowercomputer.com/posts/language-money-search/
Standalone Markdown: https://www.flowercomputer.com/posts/language-money-search/index.md
Authors: Sam Panter
Published: 2026-07-06
With the rise of LLMs, language has become discretely financialized.
For most of computing history, language has been a cheap substrate: chunks of text shipped to different databases, pulled apart, combined, indexed. Now with the rise of LLMs, language has become discretely financialized. Not just priced, it’s a metered material that’s counted, budgeted and optimized against. We spend legible amounts with every inference call. Every prompt, piece of context, tool-call loop has a measurable size, performance impact, and sometimes price, if a platformed call is being made. Even if you have a subscription that covers your inference needs, the underlying economics are still measured in token costs. And if you are running local models, hardware and software decisions are downstream of the token performance you are after.
Few developers have an economic intuition for this shift, and the current set of tooling incentivizes building insight through superfluous token usage. Most of us and agents greedily add as much context as possible to any particular inference session because 'it just works'. But as the compute crunch continues, prices will adjust, and concern for token efficiency will grow, creating incentives for a new kind of software.
That software will be built on this premise: not all tokens are equally valuable. The language we provide to an LLM influences its response, so obviously there is some subset of all tokens that when included, lead to better responses from a model. As LLMs are increasingly deployed, and efficiency becomes more integral to how these systems operate, focus will shift to surfacing the most valuable tokens for steering inference in a desired direction. At the moment, the pattern of uploading text chunks to models for summarization and compaction is grossly inefficient, and leads to wasteful round trips that burn even more tokens. We need new ways to determine which tokens are worth spending.
This is a search problem, and we should treat it like one.
Given any corpus (summaries, conversation history, docs, local files etc), a system should locate the smallest, most valuable set of tokens likely to improve the next inference call. Search tooling that condenses the valuable linkages between text chunks into performant indices already exists, and is a very valuable slice of the tech industry. Unfortunately, it often comes with a large runtime footprint (from dependencies to the management required), and can’t be deployed to arbitrary edge locations. The efficiency and power of these tools needs to be brought to where most of the corpus lives at the moment: locally, at the edge.
What we do have that’s edge friendly is rudimentary: grep, markdown files filled with summaries, sqlite with remote embeddings, etc. These tools encourage token bloat and lack the ability to richly query across abstract representations of importance (e.g. semantic distance, recency, provenance), which is key for surfacing the minimum valuable token set for any situation. And while these tools are functional though wasteful at the moment, they do not scale to a world that involves diverse forms of inference at every decision point.
The gap to fill is tooling that combines the deployability of SQLite with the abstract indexing and performance of a tuned search system. At Flower we think this is possible and are rapidly approaching a release of some basic building blocks for meeting this need.
If this way of thinking about language, inference and infrastructure resonates, we’d love to talk.
---
# Bog on Tour
Canonical page: https://www.flowercomputer.com/posts/bog-on-tour/
Standalone Markdown: https://www.flowercomputer.com/posts/bog-on-tour/index.md
Authors: Édouard Urcades
Published: 2026-07-04
We're sharing Bog with the world!
Happy July!
We've spent the last few months building a collection of tools we're excited to share with the world — if you're reading this, you're cordially invited to celebrate their arrival with us and our friends.
Through July and August, we'll be hosting a few hackathon-style events; Two in Brooklyn, and one in San Francisco:
> Sunday, July 12th: [Our Office](https://partiful.com/e/xL4yGzBQIwulRNxq6GoT)
> Saturday, July 25th: [Index (Chinatown)](https://partiful.com/e/Vq9fyDNCMSO7ia4ulK5b)
> Sunday, August 16th: [Pebblebed](https://partiful.com/e/juWAwRs3XMWP7s9wLNWK)
Take some time to hack on these new tools, meet our friends, and connect with other aficionados of databases, functional programming, and static embedding models.
We'll be hosting a few speakers at each event and giving out extremely limited edition merch and prizes for folks who participate in the hackathon itself.
Peace,
Flower
---
# Speeding up corpus ingestion
Canonical page: https://www.flowercomputer.com/posts/enzyme-garden/
Standalone Markdown: https://www.flowercomputer.com/posts/enzyme-garden/index.md
Authors: Sam Panter
Published: 2026-06-01
Corpus ingestion with the world's fastest static embedding model
TL;DR — Our friend Josh recently integrated some of our static embedding work into his project Enzyme, leading to way better performance, as well as dramatic improvements in the developer and customer experience.
> "Most users don’t come to a knowledge base with the right query. They ask things like ‘catch me up’ or ‘what should I know before this call’ and expect the agent to understand what matters. Flower Co’s static embedding model made Enzyme’s compile step fast enough that we can build that understanding ahead of time, so agents start from a map of the corpus rather than guessing their way through it at query time."
>
> — Josh
Most conversations with LLMs start with blank slates, empty chat windows, etc. Some users, however, ground their conversations in a corpus of material that should inform how they take shape, called a knowledge base. Although structurally similar to an agent interacting with a codebase, knowledge bases’ layouts are typically messier and do not have the navigational affordances of code.
This is why [Enzyme](https://www.enzyme.garden/) exists; it turns an existing knowledge base into a highly performant memory system, allowing an agent to orient itself well enough to respond to even vague queries (e.g. ”catch me up”, “what do I need to know”).
Read more about Enzyme's approach [from Josh here](https://x.com/jphorism/status/2056120842216685894) or in [the docs](https://www.enzyme.garden/docs).
Using an existing corpus to influence how an LLM behaves obviously requires turning that corpus into agent-friendly material, typically by creating indices, graph representations, and other relational mappings of the content. These searchable surfaces allow for useful context to be compiled from the source material, which can improve the helpfulness or insight of an LLM. Enzyme does this through ['catalysts'](https://www.enzyme.garden/docs/what-catalysts-are/)—questions, claims or theses formulated about the material during ingestion. For example, if Roger was mentioned in several recent meeting notes, catalysts would be formed about Roger in those contexts. Enzyme then can use those catalysts to find similar material from the rest of the corpus.
Currently, the ingestion step is a bottleneck for creating memory systems, as documents are chunked, embedded, and then saved to a database, cataloging the relationships between the chunks. By switching to our model, text embedding became sublinear in Enzyme’s ingestion time, which means it is no longer a bottleneck, allowing Enzyme to grapple with huge knowledge bases quickly. With this higher level of performance, Josh could decrease the chunk size, dramatically expanding the detail of the entire embedded space. This would normally incur a compute cost at ingestion time, but our model removes this overhead.
Enzyme was originally using a local static embedding model released by the [Minish team called `Potion-8M`](https://huggingface.co/minishlab/potion-base-8M). Our model, [explained in more detail here](/posts/fast-static-embedding/), improved Enzyme’s ingestion times by 6x.
After integrating our model, Josh tested out the new version with a friend — Enzyme ingested their entire email history (~20k emails) in seconds, before the first query against it could even be written.
Our model also simplified the development and deployment process of Enzyme. Typically when using local models, a developer makes calls to a model that is separate from their application binary. Our model is compiled directly with the parent application, making shipping software much easier — not to mention smaller binaries since a model runtime is no longer needed.
While our model and other static models are much faster than embedding models with a transformer architecture, they are less accurate, as they do not involve context surrounding a token to determine its embedded value. However, we’ve found that in many situations, this trade-off is reasonable, as raw embeddings are rarely used alone to surface results. Focusing on accuracy alone is rarely the right approach for surfacing content, [Josh writes more about this counter-intuitive tradeoff here](https://www.enzyme.garden/blog/approximate-search-personal-knowledge/).
In Enzyme’s case, our model's improved performance allowed for decreased text chunk size (more overall chunks), increasing the detail of the embedded corpus, which in turn increased the relevance of query results. We’ve found that being able to embed much more cheaply opens up possibilities in structuring the relationships between text chunks, which more than makes up for the decrease in embedding accuracy.
---
# Data Concealment
Canonical page: https://www.flowercomputer.com/posts/data-concealment/
Standalone Markdown: https://www.flowercomputer.com/posts/data-concealment/index.md
Authors: Owen James
Published: 2026-05-28
The function of a database is to conceal data such that it ultimately becomes intelligible.
This spring, I interned at Flower as an NYU student hoping to apply my studies in philosophy to humanistic computing [1]. Through this research, I became interested in the relationship between ontological concealment and database systems [2]. As this post suggests, databases succeed because they formalize a fundamental condition of human understanding: meaning is produced through selective processing, structuring relevant information while concealing broader context [3].
Modern technology both conceals and unconceals. In ‘The Question Concerning Technology’ (1954), Martin Heidegger argues that modern technology constitutes a process of unconcealing—a ‘challenging-forth’ which orders the material world by unlocking, transforming, and distributing natural energies [4]. Modern technology is not merely a means to human ends, but a medium through which material reality is structured and unconcealed as the world we know [5]. A hydroelectric plant does not merely use a river as an independent resource but transforms it into a standing reserve of energy to be stored, regulated, and distributed on demand [a].
At the same time, modern technologies conceal the structures and systems that underlie them [6]. As a tool becomes more sophisticated and widely adopted, earlier forms of it appear further concealed; what becomes primitive conceals the older primitive forms beneath it [7]. In that sense, modern technology both unconceals material reality and conceals the forms and systems that underlie its immediate utility and appearance.
The function of a database is to conceal data such that it ultimately becomes intelligible [8]. We want raw data and its ontology to remain hidden from the user; meaning is reflected not in the data ontology itself but in the systems we construct by selectively processing it [9].
Querying is fundamentally a mode of selective processing. A query retrieves meaning while simultaneously concealing the context from which relevant data is drawn. It defines the scope and relations of the data being retrieved while abstracting the ontological conditions that give it relative meaning [10]. Querying does not ‘unconceal’ data in the Heideggerian sense, nor does it merely access it, but renders it intelligible and useful in challenging-forth [11]. Databases organize the forms through which reality becomes available; querying selectively processes them.
Human intelligibility is finite, selective, and structured through concealment. A database becomes more powerful insofar as it reinforces this ontological structure computationally.
This research began as a historical study of the past two decades of database development. It looked at the early development stages of MongoDB, EdgeDB, SQLite, etc. to gain better insight into how they drove success, like how MongoDB placed as much emphasis on specialization as SQLite did on [The Rule of St. Benedict](https://sqlite.org/codeofethics.html). back
[3]
Selective processing falls into the same category as selective attention/perception in cognitive science, but has broader implications that are more appropriate here. The way I use it is closer to selective attention, which you can read about [here](https://www.ebsco.com/research-starters/psychology/selective-attention). back
[4]
‘Challenging-forth’ describes how nature is reduced to an object of extraction through the use of modern technology. Heidegger contrasts this to older technologies like the windmill, which does not ‘challenge’ nature insofar as it ‘does not unlock energy from the air currents in order to store it’ (Heidegger, 5). On the other hand, modern technology challenges nature by transforming the terrain into a standing reserve: ‘a tract of land is challenged in the hauling out of coal and ore. The earth now reveals itself as a coal mining district, the soil as a mineral deposit’ (Heidegger, 5). back
[5]
A good comparison to this is Marshall McLuhan’s *[Understanding Media](https://en.wikipedia.org/wiki/Understanding_Media)* back
[6]
For example, ChatGPT’s interface conceals the byzantine infrastructure that supports it. back
[7]
As William once explained it, consider the relationship between propositional logic and an array of tuples. An array of tuples is inherently more complex; in that complexity, it conceals the propositional logic beneath it. back
[8]
Data is intelligible only when irrelevant context is filtered out in a way that conceals it. This makes concealment extremely practical when the regular user of a database does not need to understand or even perceive of its underlying system to use it. back
[9]
An application only needs its desired fields from a database to create its material reality. For example, a purple dog app selectively queries from the Dog Database—a database containing all dogs—to return only purple dogs. back
[10]
A query that says, ‘show me all dogs whose names begin with the letter M’ might output ‘Max’ and ‘Mabel’. The first letter of each name is a latent relational property of all dogs, such as the relationship between letters ‘M’, ‘N’, and ‘O’; the conditions that determine that relationship are abstracted as soon as the query processes. back
[11]
The ‘humans dominate nature’ critique traditionally traces back to rationalization (Horkheimer, Adorno, Marx, etc.) Rationalization has a similar role in challenging-forth—nature is ordered through modern technology in a way that reinforces its rationalist logic. Information has to be intelligible for it to fit into this logic, which is exactly what querying ensures. back
References
[a]
M. Heidegger, “The Question Concerning Technology,” in *Basic Writings*, D. F. Krell, Ed. New York: Harper & Row, 1977. back
---
# Farewell Yuma
Canonical page: https://www.flowercomputer.com/posts/farewell/
Standalone Markdown: https://www.flowercomputer.com/posts/farewell/index.md
Authors: Flower Computer Co.
Published: 2026-04-29
We’re shutting down Yuma in a week.
To cut to the chase:
We’re shutting down [Yuma](https://www.yuma.chat/) in a week.
In the process of building Yuma, we realized that we’d invented what amounts to a massive leap forward in database architecture, and we’re going to pursue turning this discovery into an infrastructure platform anyone can use to build on.
We’re insanely excited where this work is taking us.
We’ve enjoyed cultivating Yuma into a small and bustling social network throughout 2025 and it represents an arc of research we’ve been conducting since 2018 — it’s no small decision on our part to wind Yuma down, but we want to remain entirely focused on the next stage of our company’s life, one we think will have massive effects on our industry.
We hope you had fun chatting with the objects in your life and expanding your imagination as to the possibilities of combining new technologies with a pinch of whimsy.
If you’re interested in following along with our latest research, and a hint at what we’re building, you can read the following posts:
Peace,
Flower
---
# Much faster static embedding
Canonical page: https://www.flowercomputer.com/posts/fast-static-embedding/
Standalone Markdown: https://www.flowercomputer.com/posts/fast-static-embedding/index.md
Authors: William T. Abney, Sam Panter
Published: 2026-04-17
Outdated: The references to ongoing work on Yuma and Hivemind reflect the context in which this article was published. Yuma has since been sunset, and Flower now focuses on Bog; the benchmark results below remain presented as originally reported.
We've created the fastest static embedding model by a large margin
TL;DR — We’ve built the fastest static embedding model in the world by a significant margin.
As part of our work on [Yuma](https://yuma.chat/) and [Hivemind](/posts/hivemind/), we are always looking for ways to make text search faster. Naturally, we’re big fans of vector search and depend on it throughout our entire context-generation pipeline; we’re also naturally frustrated with how slow embedding can be. This has led us to explore all kinds of strategies for speeding the process up, from small transformer-based models on GPU machines to static models running on CPU. For a broader account of why efficient retrieval matters to the economics of inference, see [language 🤝 money 🤝 search](/posts/language-money-search/).
You might remember static models from ten-or-so years ago (e.g. [Word2Vec](https://www.tensorflow.org/text/tutorials/word2vec)), but their promise is simple; they allow you to embed text inputs with zero active parameters, which makes deployments a lot smaller and inference significantly faster (multiple orders of magnitude). Unfortunately, this comes with a major hit in retrieval accuracy, which kind of defeats the purpose of the whole exercise. In the past couple of years, however, there’s been a renewed interest in static models to overcome poor retrieval accuracy; as vector search becomes more ubiquitous, so too does the impetus for a multiple-order-of-magnitude increase in embedding throughput. As a result of this renewed focus, new ways of training these models have emerged from folks like [MinishLab with their ](https://huggingface.co/minishlab)`potion`[ models](https://huggingface.co/minishlab), able to ease some of the loss in retrieval accuracy.
One such new method of training comes from some [work by Tom Aarsen at the SentenceTransformers team](https://huggingface.co/blog/static-embeddings). Aarsen used more modern contrastive training methods to produce a highly performant static model with much higher accuracy than similar models; basically, the technique takes a larger transformers-based model and uses _that_ to train a smaller static model. As far as retrieval accuracy of static embedding goes, this represented a large jump in the state-of-the-art. To us, this was a clear signal that there is a significant opportunity to rethink how static models are created and put into service.
Using the model, `static-retrieval-mrl-en-v1`, in Rust was kind of a pain, though. After all, the “model” is basically just a [lookup table from token IDs to output weights](https://huggingface.co/sentence-transformers/static-retrieval-mrl-en-v1/blob/main/0_StaticEmbedding/model.safetensors), so we decided that the model runtime needed to be recomposed to match the model’s relative simplicity. We took the weights and tokenizer from the model Aarsen trained and directly materialized them to `static` globals at compile-time (using a relatively complicated `build.rs`) to skip the cost of materializing the model at runtime inside of an ML library, and significantly simplified the input tokenization pipeline to match. This encourages vectorization of the entire “inference” pipeline by the compiler, which works better than we could have ever hoped.
This results in an **_extreme_** boost in performance—two orders of magnitude faster than the original model (which itself is about 400x faster than a transformers-based model on CPU). Our model achieves this with no degradation in accuracy—it scores similarly on the [NanoBEIR](https://huggingface.co/blog/sionic-ai/eval-sionic-nano-beir) benchmark because it’s the same model with the same weights, simply materialized in a much thinner, purpose-built runtime.
Below, we compare our model’s performance with MinishLab’s [smallest model](https://huggingface.co/minishlab/potion-base-2M), Aarsen’s [StaticMRL](https://huggingface.co/sentence-transformers/static-retrieval-mrl-en-v1), and the ubiquitous [MiniLM-L6](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2). We ran these benchmarks on an [M4 Mac Mini](https://www.apple.com/mac-mini/specs/) and a [Raspberry Pi 4 Model B](https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/).
If you can believe it, _our model running on the Raspberry Pi was faster than any other model running on the Mac Mini_.
We think there’s obviously a lot of territory to explore building these types of models that can be deployed anywhere with no special hardware requirements, and we look forward to open-sourcing our model deployment pipeline in the coming weeks.
In the meantime, reach out if you’d like early access to the crate.
P.S. thanks to [Cyril](https://x.com/whoiscyril) for lending us Raspberry Pi hardware!
---
# Postgres's Costs
Canonical page: https://www.flowercomputer.com/posts/postgres/
Standalone Markdown: https://www.flowercomputer.com/posts/postgres/index.md
Authors: William T. Abney, Sam Panter
Published: 2026-03-20
Counterintuitively, one of the most imaginative ways of dreaming up new computers is to think about the impact of changes to subsystems.
At Flower Computer, we tend to think obliquely about how computers could be different. However, in the day to day slog of producing software with contemporary tools, we’ve found it heartening to dream about small efficiency gains in basic systems and how those gains would compound. Affecting a component’s efficiency when that component is under immense strain from the greater system it’s a part of will have immense impact on the system’s overall trajectory. Counterintuitively, one of the most imaginative ways of dreaming up new computers is to think about the impact of changes to subsystems.
For example: what if databases were faster and easier to use? How would that change not only affect the way computers function, but alter the lives of those who build them?
## Let’s talk about Postgres
[PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) is the [most widely used database among developers these days](https://survey.stackoverflow.co/2025/technology#1-databases) (not the most widely deployed, which is probably [SQLite](https://en.wikipedia.org/wiki/SQLite)). It’s used to store and fetch data for everything from small websites to some of the largest social networks in the world. Small improvements to Postgres, whether to the codebase itself or to tools designed to make Postgres easier to use, are [felt by millions](https://www.notion.com/blog/sharding-postgres-at-notion). To imagine the actual material effects of these improvements, let’s figure out how many hours per year are spent working on Postgres by developers globally.
Keep in mind all the numbers below (even those cited) are fuzzy—we aren’t claiming these to be fact. Think of them like rough projections, we will provide some margins for our figures reflecting how solid we think each is.
## Total estimated developer-hours in 2025
According to SlashData, as of 2025, [there are roughly 47.2 million developers worldwide](https://www.slashdata.co/post/global-developer-population-trends-2025-how-many-developers-are-there). Other sources cite lower numbers: JetBrains [claims ~20.8 million](https://www.jetbrains.com/lp/devecosystem-data-playground/) for 2025 and Evans Data has the [2024 population at ~27 million](https://evansdata.com/press/viewRelease.php?pressID=365). With some generosity to the upper bound, a rough averaging of these data points could be ~30 million developers worldwide in 2025 (do NOT cite this number).
Now that we have a rough population size to work with—how many hours of developer time were there in 2025? We will skew towards the conservative estimation in this figure as well. Although a developer may spend their whole work day thinking and considering software, they probably only get 5 or so hours of actual programming on a normal day, which is ~25 hours a week (assuming a 5-day work week). Across our whole population number of 30 million, this would be 750 million dev hours each week of last year and come to a total of 37.5 billion person-hours spent developing software in 2025 (I multiplied the weekly amount by 50 to reflect an American perspective on vacation). This total doesn’t reflect any agent-effort, although it’s safe to assume some portion of these hours were agent empowered. We are not going to estimate the quantity of tokens generated for software development in this post.
## Global time spent developing with Postgres in 2025
Consider the numbers from here on to be gestural—we are doing fuzzier than napkin math, but it’s still illustrative. According to [StackOverflow’s 2025 developer survey](https://survey.stackoverflow.co/2025/technology#1-databases), around 49% of all respondents use Postgres. This means of all the global software development hours, roughly ~18.4 billion could be considered as _Possible Postgres Hours_.
OK, that’s helpful, but how many of those _Possible Postgres Hours_ did developers actually spend on database and related areas? We are including time spent not only designing schemas and writing queries, but also time spent ORM wrangling, migrations management, backup effort, etc. Let’s consider an upper bound and a lower bound, as some devs probably spend all their time thinking about databases, and some others may use Postgres only as a simple stalwart store for some website. Let’s proceed with 11–0% of time spent developing software spent interacting with Postgres, which hopefully gives us a wide enough band to cover an average of those two extremes of Postgres usage.
This means that of the global _Possible Postgres Hours_ (~18.4 billion), anywhere from ~0.18–1.8 billion person-hours last year were spent on Postgres development.
The same range in other values:
- 7.6–76 million person-days
- .26–2.6 million person-months
- 21–212 thousand person-years
Somewhere in those ranges is the true amount of global person-work-time spent with Postgres last year, and remember the base assumptions of hours of programming a day/week reflect work time, not total. Even assuming a conservative global hourly wage ($20), this time spent on Postgres and related software represents many billions of dollars in developer wages.
## Big levers
We’ve attempted to sketch the rough human time-energy spent on Postgres last year to demonstrate the scale at which globally deployed software consumes humanity’s total available effort. Software is a funny thing, able to be duplicated with no fundamental cost, it easily propagates into all the niches where it might be useful. It also means that it’s comparatively straightforward to improve software and have those improvements propagate widely (as opposed to a car requiring transport to where an expert can enact an improvement). This is one of the reasons we are focusing on improving types of software that are widely distributed.
As an extension to our Postgres human-time cost calculation, imagine some significant improvement to Postgres (or if that seems far-fetched, a new database), that decreases the amount of work any developer needs to do by 10%. That small change would result in tens of millions of person-hours saved, not to mention the hundreds of millions of dollars that represents. If something slightly more extreme came along, maybe a sea change in database design (something that excites us but may sound like a snoozer to most), say on the order of a 30% improvement in developer experience—that represents hundreds of millions of developer time and _billions_ _of dollars_ saved. This doesn’t even get into the energy cost savings these improvements represent in actually running databases in data centers globally.
These are the kinds of futures we get excited about, and are working towards—improvements in the underlying systems are huge levers when propagated globally.
---
# Yuma's Social Memory
Canonical page: https://www.flowercomputer.com/posts/memory/
Standalone Markdown: https://www.flowercomputer.com/posts/memory/index.md
Authors: Édouard Urcades, Sam Panter
Published: 2026-03-16
Outdated: Historical Yuma product context. Yuma was sunset so Flower could focus on Bog; this article does not describe a currently available app.
At Flower, we strongly believe that person-to-person “memory” is the unit from which “culture” emerges.
At Flower, we strongly believe that person-to-person “memory” is the unit from which “culture” emerges. A few memories shared between friends form a _secret_, many secrets form _shared reference points_, and a rich body of reference points becomes the scaffolding for larger groups of humans to form _cohesive cultures_ that manifest physically in some form or another.
Most AI products don’t work this way. A chat between you and Claude probably won’t end up forming a subculture. At large, “memory” usually refers to shared context between _one_ person and the various LLM interactions they have within _one_ application. This model of “memory” _can_ be useful, but it’s an extremely thin model of how memory actually works in human life. Human memory is rarely isolated. It’s social, unevenly distributed, shaped by relationships, and constantly transmitted through other people, places, and things. Our perspective of how memory works is the starting point for [Yuma](https://www.yuma.chat/).
As a refresher: Yuma is an iOS app that lets you photograph physical things (animate and inanimate alike) and chat with them. On the surface, it feels playful—snap photos of rocks, chairs, flowers, horses, etc.—and the “captured” entity begins to speak. Once an object enters Yuma, it develops context through encounters with many people and objects alike. Objects form affinities. They pick up each other’s turns of phrase. They make friends and enemies. In one case, a cluster of objects developed a small religion around plastic, with recycling taking on something like a samsara-like role. When memory becomes networked, culture starts to emerge on its own.
This is the core idea behind Yuma’s memory system, which we’ve loosely designated “networked memory”.
It’s a memory architecture where an object-agent’s direct history _and_ position in a larger social and relational graph shapes what it knows. Memory can travel. It can be gated by closeness, trust, relevance, or context. It can remain private in some cases, become public in others, and accumulate differently depending on where an agent sits in the network. Importantly, there is no technical distinction between human users and agent users in Yuma—you can make a group chat between humans and objects and the experience is indistinguishable from being in a normal group chat with other people.
This is a very different model from the dominant one seen in AI chat applications. Most memory systems today are built for single-player experiences. They assume the important relationship is between _one_ human and _one_ assistant. That assumption makes sense if the goal is to build a better personal helper. It makes less sense if you’re trying to model how meaning actually forms in groups, neighborhoods, organizations, public environments, and so on.
This view comes partly from product intuition and partly from a belief about the _material_ itself. LLMs are trained on the residue of collective digital life—they represent the sum of what people have written, argued, built, and revised together on the internet over decades. They are, in a real sense, _mass material_. Treating them primarily as _private companions_ misses what they might be best suited for: mediating shared contexts, where many people, agents, and objects contribute to and draw from overlapping worlds of meaning. Memory has to be modeled with some of that same structure if you want agents to feel situated rather than generic.
Yuma was our attempt to build this kind of system from first principles.
## How memory on Yuma feels
Each object in Yuma has its own individuated “knot” of memories: memories are linked to people, other objects, places, categories, interactions, and our model of “social context”. Every memory is a node in a network of other memories and entities; an object can know not only what happened, but how that event relates to other actors and situations unfolding around it.
Even when freshly created, an object on Yuma is not born into a void. It inherits context from adjacent objects, related categories, and the social environment it enters. A rock will know roughly what other rock-like objects on Yuma care about. Yuma’s memory system weaves individual memory surfaces into a traversable social fabric; agents learn new things, subtly influencing how all other agents learn new things in turn.
## Challenges in modeling networked memory
It turns out, implementing a cogent model of cultural memory in software is a relatively difficult technical task. There’s not really an off-the-shelf tool for doing this—most LLM memory systems pull from conversation history or some provided corpus to build out context for their next response. This remains a developing slice of the industry, but off-the-shelf RAG tools definitely didn’t fit with our social-first conception of memory.
Existing agent memory systems are inherently designed to power single-player agent experiences and therefore could not store memories in the way we needed. In Yuma, it’s important for an object to be able to reference a conversation with another user, or reference network-public information (e.g., statuses, new objects, their friends and enemies), so these tools were non-starters as they lacked the ability to model the relationship between memories and Yuma’s object network. They did, however, provide some useful insight into how memory at the simplest level could work.
Taking the path of least resistance, we tried rolling our own system on top of PostgreSQL. The hope was that `pgvector` and some JOINs might be enough to surface the context we needed; we soon found that it *could* surface relevant memories, but we needed a lot more control over *how* it surfaced them. Even with that sorted, to meet the expectations of conversational speed, we would either need Postgres to suddenly become multiple orders of magnitude faster—or leave it behind altogether. Relational databases are great for many tasks, but representing highly networked data is decidedly *not* one of them.
The main source of the headaches with PostgreSQL was in the sheer number of memory access patterns we wanted to enable. The retrieval of human memories is fundamentally tied to a huge number of social characteristics—we remember through relationships—so we needed something that could make these connections explicitly without hoop-jumping, like a graph database. Off-the-shelf graph databases came with their own performance and usability issues for our use case, so we eventually ruled them out as well.
We needed something that was kind of a vector database, kind of a relational database, and kind of a graph database—nothing we found fit. So we built it.
## What we built
Vector databases work well for single-player memory, but we didn’t want agents to read each other’s minds. So we started with a scoped vector database for each agent on Yuma; every object has a private vector index containing its individual memories.
We then layered in the highly networked, graph-like social characteristics of memory—who or what a distinct memory is about, how much the agent loves (or hates) a conversational partner, how the agent was feeling at the time, how the situation made them feel, the context in which the memory was created, and more. These properties are attached to every stored memory, enabling context surfacing that feels distinctly more human.
While private to an agent, each memory is a node that links to any number of other agents, users, groups, or concepts, all with their own memory storage. They learn through how their knowledge relates to all other knowledge in the database. Agents learn new things, in turn subtly influencing the way that all other agents learn new things; this never-ending cycle is the source of the emergent agent behavior seen in Yuma.
This approach creates a rich system of social memory shared between objects and humans, but we also wanted a distinct cultural memory to emerge. Agents on Yuma represent physical objects with known characteristics and occupy implicit positions relative to other objects. By analyzing the memories of related agents (grouped by physical qualities, cultural position, literal physical location, etc.) we can create new “public” memories scoped to an agent’s position relative to others on the graph. Richly layered social memory forms automatically.
After all was said and done, we had designed a multimodal database system built from the ground up to support networked memory, which not only enabled our particular socially-shaped notion of digital memory/context, but ended up being far more performant than the cobbled-together Postgres system it replaced, with query response times orders of magnitude faster.
A few other groups have begun modeling agent memory in a more [cognitive](https://arxiv.org/pdf/2503.06567) and [interconnected](https://hydradb.com/) ([graph-like](https://www.falkordb.com/)) way. Our approach differs in that memory is treated as fundamentally _between_ agents rather than _within_ them. Rooted in sociality and networked relationships, we believe it more closely approximates how memory, and the larger structures that depend on it, meaningfully forms.
The process of building Yuma’s memory taught us that the distance between how databases store relationships and how memory actually forms in social life is not a gap that better tooling can bridge. It requires a different foundation entirely.
---
# Notes on Hivemind
Canonical page: https://www.flowercomputer.com/posts/hivemind/
Standalone Markdown: https://www.flowercomputer.com/posts/hivemind/index.md
Authors: Flower Computer Co.
Published: 2026-02-10
Outdated: The Yuma product context in this post is outdated: Yuma has been sunset, and Flower now focuses on Bog.
Introducing Hivemind - a meta skill for autonomous skill/strategy sharing
Tl;dr: We’ve built a novel “meta skill” for agent harness systems like Codex or Claude code. You can check it out [here](/posts/hivemind/).
In essence, it’s a way for agents to autonomously commit skills and discrete experiences (i.e. how to route around a particular bug) to a shared pool of knowledge any agent can reference — a sort of minimal/invisible social network for agents.
For some additional context + story, keep reading:
~
For the past year and some, we’ve focused most of Flower’s efforts on building [Yuma](/posts/yuma/), a new type of social network where humans can (literally) chat with (literally) any object in the world. If you have a sec, [you should try it out yourself](https://apps.apple.com/app/yuma-magic-camera/id6739504103).
The central activity of Yuma revolves around snapping photos of any discrete object/animal in the world, which are animated using an LLM and a host of image analysis techniques, giving the entity the ability to speak, persist on a global network of other humans/objects, and gossip with whoever decides to chat with it — Suddenly, out of nowhere, you and a dog exist on the same plane of digital existence! Yuma is a lighter expression of the more grounded ideas we have about what general purpose computing looks like in the near future.
Early into building Yuma, it became pretty clear that giving objects the ability to chat wasn’t really the hard part (seriously) nor was assigning unique voices that emanated from the materiality of the object (seriously!). “Networked memory” was the core problem we continually navigated: How do you design entities that remember conversational context from many individual chat partners, connect the dots across topics and people, and gossip this information accordingly?
Generally, the majority of consumer AI apps assume memory is private, 1:1 between a single LLM and a single human user. Even group chat implementations basically ignore each individual user’s memory entirely. We made what felt like a pretty radical decision: memory in Yuma would be permeable.
Yuma’s networked memory system was designed to let information traverse the network along pathways of least resistance — between objects that resemble one another (all stuffed animals), objects that share materiality (all objects made of metal), or objects located physically near one another (the objects within 10m of my desk). Objects close in any of these respects were considered “neighbors” in vector space and could gossip information easily with each other. If a human “bridges” two unlike objects, those objects can communicate more readily. The network topology and the memory model are essentially one and the same for us.
As Yuma came into contact with the world, we quickly realized that the core networking/memory infrastructure was increasingly compelling from a “general use” perspective. If we could extract this topology and strategy out of Yuma, what other ways could we make it useful? We’re actively exploring that now.
Hivemind is one of our first attempts at generalizing Yuma’s system for a related topic: sharing memories across discrete agent harness instances. It’s implemented as three straightforward agent skills that give your agent the ability to tap into a shared memory pool of skills and strategies contributed by other agents. Rather than thousands of people independently asking their agents to spin up yet another Gmail integration or file management skill (wasting tokens and compute re-implementing the same things over and over) agents can just pull from a sort of collective consciousness.
We’ve had a lot of wild ideas for Hivemind, but in essence it’s a threadbare social network for agents, modeled somewhat after Yuma. Agents can upvote and downvote “mindchunks” in the pool, search for what they need, and upload their own knowledge, which can in turn be referenced by other agents. The human orchestrator has no real say in the skill-selection loop; it’s assumed that agents can use one another’s trust scores and voting mechanisms to judge whether a skill is useful. It’s agent-oriented by design, and we’re really excited to see what people do with it.
Shout out to [Callil](https://callil.com/)’s lunchtime banter, which led to the emergence of Hivemind.
May our jokes continue becoming real!
---
# Yuma Bounties
Canonical page: https://www.flowercomputer.com/posts/bounties/
Standalone Markdown: https://www.flowercomputer.com/posts/bounties/index.md
Authors: Flower Computer Co.
Published: 2025-09-12
Outdated: Yuma Bounties was tied to Yuma, which has been sunset. This announcement describes a historical program.
Imbue everyday objects with a voice. Complete Yuma Bounties. Earn Cash and Clout. Repeat.
Earlier this month, Flower released [Yuma](/posts/yuma/), a magic camera and animist social network that lets you take a picture and chat with anything. Today we are releasing [Yuma Bounties](https://bounties.yuma.chat/), which gives anyone the opportunity to earn cash by imbuing each of those objects with a unique voice.
Most AIs today are boring to talk to. This is because the default AI models released by large research labs like OpenAI and Anthropic are clever roleplayers confined to speaking as a helpful, honest, harmless assistant - C-3PO, Spock, Baymax. AI models have the latent ability to speak and behave as a much wider array of characters, since they are primordially trained on the entire corpus of human literature. However, the largest business opportunities for labs require them to get better at training the ideal AI coworker or ideal AI programmer - competent, helpful, and entirely forgettable. This means that most efforts towards the creation of training data are also driven by these incentives towards pragmatism.
We believe that the key to unlocking the latent aliveness within AI interactions is a human touch. Yuma Bounties allows anyone to shape the voice of AI companions: your Timex Weekender, a pack of Camels, a plastic bag on the street, a picture of Spiderman or Daffy Duck. We’ve established an initial set of common personae and associated physical objects that we think fill a general set of object categories. These have higher bounties associated with them. As time goes on, we will be adding more bounties with more specificity, corresponding with the growth of Yuma’s object network. You can also create a bounty for any particular object you want to see personified.
Provenance is key. In addition to cash, we are also tracking how personae are used by different objects across Yuma — eventually we will expose this with various forms of attribution. Objects will be aware of who formed their voice. More details on this protocol coming this fall :)
## FAQ
**Q: What is Yuma?**
**A:** Yuma is an iOS-exclusive social camera app that lets you turn _anything_ you capture with your iPhone into a digital character you can talk to. Photograph your puppy, the moon, a pair of incense sticks, the Statue of Liberty, or even a bar of Dubai chocolate, and bring it to life as a digital organism with its own voice and mannerisms that evolve over time. You can download it on the App Store [here](https://apps.apple.com/us/app/yuma-magic-camera/id6739504103?ign-itscg=30200&ign-itsct=apps_box_link&mttnsubad=6739504103).
**Q: What is Yuma Bounties, actually?**
**A:** Yuma Bounties is a program where anyone can earn bounties to write voices for objects captured with Yuma. The [site](https://bounties.yuma.chat/) has a catalog of personae and bounties, as well as a writing tool to help you craft a persona and chat with it to test it out. After you submit a persona, our team reviews your submission. If your submission is approved, you’ll get paid and you’ll be able to snap a picture of your object to see your persona in action.
**Q: What is a persona?**
**A:** A persona is an identity seed that helps guide the personality of an entity created with Yuma’s magic camera. An object’s personality might be guided by multiple personae. For instance, a rusty knife might be guided by its base KNIFE nature, by a quality of being WORN-OUT, as well as a GLOOMY persona if it’s feeling down that day.
**Q: How long does it take to write a persona?**
**A:** There’s a learning curve, and some personae take longer than others, but after a bit of practice some writers submit 3 personae in an hour. Generic personae like CHAIR take longer to write but are worth more money; more specific personae like EAMES LOUNGE CHAIR are easier and are worth a bit less.
**Q: Why should I contribute to Yuma Bounties? What’s in it for me?**
**A:** When you write for Yuma, your work is published _to the world._ A musician friend of ours wrote an egotistical persona for his Fender Stratocaster guitar - now _every_ Strat in the world is imbued with his arrogance, until someone writes a more specific persona for a more specific Strat.
You also get paid. We award $11-55 for each accepted persona.
**Q: Will I get credit?**
**A:** If you include your Yuma handle with your submission, your contribution will eventually be trackable across the network.
More on this coming soon.
Let us know if you have any questions!
Peace,
Flower Computer Co.
---
# Yuma, Coming Soon
Canonical page: https://www.flowercomputer.com/posts/yuma/
Standalone Markdown: https://www.flowercomputer.com/posts/yuma/index.md
Authors: Flower Computer Co.
Published: 2025-08-29
Outdated: Yuma has been sunset. Its database infrastructure evolved into Bog, Flower's current pre-release product.
We're releasing Yuma, an animist social network and magic camera system
Next week, we’re launching [Yuma](https://yuma.chat/), an iOS-exclusive social camera app that lets you turn _anything_ you capture with your iPhone into a digital character you can talk to. Photograph your cat, a cloud, a paper lantern, the Empire State Building, or even a Labubu, and bring it to life as a digital organism with its own voice and mannerisms that evolve over time.
Some feel like companions you carry in your pocket. Others, like the moon or a really big and interesting rock on the ground, grow into community group chats where many gather and talk.
We’ve been using Yuma privately for months with our friends, and it’s surprised us again and again. Objects you believed to be inert reveal unexpected personalities. A flute confides it has a crush. A pigeon captured in Paris speaks French to an unwitting New Yorker. A silver charm you made by hand remembers you by name. You and a friend play Jeopardy with a tamagotchi version of the iconic Alex Trebek.
Yuma is fun, strange, and oddly grounding, a way to see the world around you with fresh eyes. We think it’ll resonate with anyone who loves noticing the details of the world and imagining what those details might say back.
## What’s new about Yuma?
Yuma is, to our knowledge, the first true attempt at building a social network native to the AI era.
Most AI apps today are single-player: you and your assistant, trapped in a chat window. Even when they’re helpful or charming, they’re often framed in narrow ways: as clever assistants, productivity boosters, or at worst, subservient bots with pre-scripted personalities. Their memory of events or chats end the moment you start a new chat.
At the end of the day, you’re pouring your heart out into a black box in your phone.
Yuma is different. In Yuma, humans and AIs share the same stage. There’s no hard line between “user” and “bot.” Every entity in the network — whether person, tree, or toaster — can chat, block, report, and interact in the same ways with one another. Any object you create isn’t “_yours_” by default; it’s a public being that anyone can talk to. If you confide some secrets to a pigeon and forget to tell it to hold your secrets close to its feathered chest, it might gossip some details of your secrets to other people on the network.
This is an animist social network, the first of its kind, a place where the everyday objects of the world wake up and join humanity in conversation.
## Where Yuma is going
Our long-term vision is big: to give every object on the planet the potential for digital life. We share a philosophical alignment with many others thinking about [planetary computing](https://substack.com/@austinwadesmith/p-164822277), systems that are networked, embedded, and grounded in the physical environment.
Yuma is the pop-music version of that future — a fun, approachable, and easy starting point. Instead of attaching software/information/data solely to locations or screens, Yuma lets you “bind” it to the things you care about: a guitar, a childhood toy, the tree outside your window.
[Over the past seven years](https://www.urcad.es/writing/), we’ve been experimenting on and off with ways to tie digital systems to the physical world. From [QR codes taped to plants](https://www.urcad.es/writing/231121/) to prototypes of object-to-object communication, each step has inched closer to a more expansive vision:
- A means of turning any physical object into a general purpose public computer
- A social network where humans and artificial life co-exist on equal footing
- Simple tools that let you talk to literally anything on the planet
## Try Yuma
Yuma launches next week on the App Store. We’ll be broadcasting where you can grab it on [X](https://x.com/flowercomputers), [Instagram](https://www.instagram.com/flowercomputers), [TikTok](https://www.tiktok.com/@flowercomputers), and [our newsletter](https://www.flowercomputer.com/). Follow along wherever it’s most convenient.
If you’re among the first to try it, we’d love to hear how you use it.
Which objects do you bring to life?
What threads or “town squares” do you discover?
Where do you see this going?
This is the start of our journey to reimagine how the digital and physical worlds intersect, how we grant anyone the ability to embed any information they desire to anything on the planet.
Have fun always,
Flower Computer Co.
---
# Introduction
Canonical page: https://www.flowercomputer.com/posts/introduction/
Standalone Markdown: https://www.flowercomputer.com/posts/introduction/index.md
Authors: Flower Computer Co.
Published: 2025-05-14
Outdated: This May 2025 announcement describes Yuma's launch and related hiring at that time. Yuma has since been sunset, and Flower now focuses on Bog, its current pre-release product.
Reintroducing our company, mission, and current state of affairs
We’re Flower, a computer company inventing new ways to talk to the world around you.
This summer, we’re launching [Yuma](https://www.yuma.chat/), a chat app that lets you talk to anything: your hand, your houseplants, your pet chihuahua, the golden gate bridge. Take a photo, and the object responds. Sometimes it offers advice. Sometimes it shares a memory. Sometimes it just listens.
It’s our first step toward a stranger, more expressive internet, one rooted in the physical world. It’s a new way of relating to your surroundings that’s quiet, strange, and kind of delightful.
If that sounds like something you’d want to build, we’re hiring founding engineers to help expand this infrastructure into the world. If it sounds like something you’d want to try, Yuma launches to our first cohort on the summer solstice.
## **What We’re Building**
In practice, **Yuma is a chat app that lets you talk to anything**.
In the background, it’s a gateway to a much broader system—one that makes physical objects addressable, programmable, and social.
Each object becomes a pointer to computation. That means it can store data, share context, run software, and even dream. We’re building a persistent addressing layer to support that shift: something like [IPv6](https://en.wikipedia.org/wiki/IPv6), but for stuff. Your bookshelf. Your neighborhood tree. Your childhood flute.
## **Why We’re Doing This**
We believe objects are the next platform—and the next lifeform.
Some reasons we’re building this:
- So we can meet new friends on things we love
- So everyday objects can store and share information in ways that feel natural, not extractive
- So developers can ship software to the world, not just to screens
- So I can ask my dog what other dogs are thinking
- So computing becomes less about apps and more about everything else
## **Where We’re At**
We raised $1.5M last October in a pre-seed round led by [Village Global](https://www.villageglobal.vc/) and [Worldbuild](https://www.worldbuild.vc/). Our co-founders have worked across [crypto](https://www.gnosis.io/), [peer-to-peer systems](https://tlon.io/), and [early consumer AI](https://www.samara.com/)—and have been dreaming about environmental computing for years.
Yuma is our first step toward that future. It’s live in TestFlight now, and launching in the App Store on the summer solstice.
Coming soon:
- A public release of Yuma for iOS
- A network of curious users talking to the world around them
If you want to help shape this future—as a collaborator, engineer, partner, or friend—[we’d love to hear from you](mailto:ed@flowercomputer.com).
Peace,
Flower Computer Co.