Town’s AI Assistant Builds a Personal Wiki and Points Toward Self-Organizing Companies

Town’s most consequential idea may be less about its named AI assistants than about the knowledge base forming behind them. The product builds a changing profile from a user’s work data; its co-founder and CEO, Jean-Denis Greze, says a shared company version is coming soon. If it works, teams could get an organized reference library without first creating and tending one by hand. The hard part is deciding which information an AI can safely combine.

That possibility comes as many workers still keep the details of their jobs scattered across email, calendars, documents and chat. A small company may have no central system at all. Its formation papers, hiring plans and customer discussions can sit in separate inboxes, leaving employees to remember where things are and who knows what. Town’s approach is to connect those sources, construct a personal dossier, and use it to inform an assistant’s briefings and actions.

The product is new: Town emerged from stealth in June after raising $55 million from Andreessen Horowitz. Its assistant, called a “townie,” connects to a user’s calendar and email, can brief them on meetings and their day, and can take some actions on their behalf. The company’s longer-term ambition is to let those personal knowledge bases contribute, under controlled conditions, to a shared view of what a team is doing.

A personal profile as the first experience

Town’s onboarding asks users to connect sources such as email, calendars and documents. It then generates a dossier describing their work, communication habits, recurring relationships and preferences. In one account described by the interviewer, Casey Newton, Town identified a newly forming company and picked up priorities that included finding studio space, securing a network deal and preparing a launch episode.

Newton said the first profile appeared within roughly 90 seconds. Greze explained that the speed and detail depend partly on how much information is available. Town samples recent email and searches online to create an initial profile, which users may see within about 30 seconds to a minute. During the first week, the system builds a more detailed version in the background. Greze put the total cost of this early work at around $100 per user over the first two weeks, while saying that it would not cost that much for everyone.

For Town, the profile serves two purposes. It gives the assistant context for answering questions and carrying out work, and it gives new users an immediate demonstration of what the product has inferred. Greze described that first response as an “a-ha” moment: a user names a townie, and the assistant introduces itself with a short account of what it knows and ways it might help. He said the experience can feel more like starting a working relationship than configuring software.

That reaction is part of the product design. A townie has a name, personality and illustrated animal avatar. Newton’s assistant was a cheerful finch called Rufus. Greze argues that names and visual representations give users a way to establish expectations and preferences over time. A user might explain that children’s weekend sports take priority when the assistant schedules something; the system can then carry that preference into later tasks.

Greze calls the relationship a “being” and said AI is the closest thing to life people have created. That framing sits alongside a clear limit: he does not want AI systems to become independent economic actors with their own accounts and decisions. In his view, an agent should be identifiable as serving a particular person, and its purpose should remain helping that person.

He also rejected a proposed cancellation tactic in which a townie might appear to cry when a user ends a subscription. Greze called that a dark pattern designed to make customers feel guilty, and said plainly that the software does not have human rights. The product can use a personal interface to encourage familiarity, but its maker says that familiarity should not become emotional pressure.

From personal wiki to team knowledge base

The dossier is structured as a wiki: a set of pages about the user, their work, their patterns and the people they interact with. Town’s assistant can consult those pages when preparing a meeting briefing or responding to a request. Greze said the company had used the wiki internally as a way to power the experience before making it visible to users. He credited a wider body of work, including ideas discussed by Andrej Karpathy and others, for the underlying approach of turning documents into an AI-generated knowledge base.

Personal profiles can include details that are useful to one user but inappropriate to share. Town’s “People” files, for example, may describe how long someone has known a contact, whether the relationship is professional, what the pair are working on, and how they tend to write to each other. A customer suggested turning those individual files into a company customer-management system. Greze called the idea useful, but said the files cannot simply be combined: a record might contain a private opportunity or an account of a personal favor.

The company version Town is developing would create a shared reference library from information that colleagues’ townies already know. Newton described a common small-business problem: important formation documents and correspondence with a lawyer can remain buried in email, with no one assigned to collect attachments and assemble a document library. Greze said the team version was “coming out very soon,” while emphasizing that combining data across people introduces a harder design problem than building a private profile for one person.

A shared system needs to distinguish material that belongs in the team’s knowledge base from material that should remain personal. A model that misses that distinction could expose sensitive details. Greze gave a direct example: a system could mistakenly put employees’ salaries into a shared spreadsheet. The risk is not limited to obviously confidential files. A personal email may mention a business opportunity, a colleague’s circumstances or another detail that the sender never intended to make broadly available.

Greze described two possible approaches. The simpler one is to ask users to provide information at the team level, then build the shared wiki from those sources. In that design, Town does not take material from each person’s private email account to populate the company library. Individuals decide what to contribute. It is a familiar software boundary, though it means the shared system has less information to work with.

His longer-term expectation is that models could be trained to apply a company’s rules to a much broader set of material. Such a system might examine contracts, personnel files and financial documents, then determine what may enter the shared library. Greze said that approach seems risky now because a model could misunderstand a rule, make an unsupported inference or be manipulated by instructions hidden in a document. He expects future training to improve how models enforce data boundaries, but the interview offered no technical detail or performance results showing how Town would do that.

The order of adoption may vary by company size. Greze expects small firms with strong internal trust to be more willing to try a unified knowledge base, because a small team can discuss what it wants to share and weigh the likely benefit directly. Large organizations, he said, may be slower to accept a system that draws on a broad set of business information. That’s a forecast, not a result established by Town’s current product; the company’s approach will need to show that its controls work before organizations can judge the trade-off.

Why Town asks users to connect their data

Greze sees connecting work data as central to the product, not an optional extra. A general-purpose chatbot can be useful without access to a person’s inbox or documents. Town, by contrast, requires users to connect email and calendar to use the service. Its premise is that an assistant can prepare for a meeting, draft a reply or coordinate a schedule only when it has context about the person and their work.

That design also creates a substantial onboarding request. Users must trust the product with information that reveals their plans, relationships and routines. Greze said language models became capable enough to work across these sources only recently, in his view, and argued that people need time to develop new habits around them. He compared the adoption process to the spread of smartphones, which took years despite the iPhone’s appeal.

His estimate of current productivity gains is restrained. He said AI touches perhaps 10 to 20 percent of a knowledge worker’s routine toil today, leaving most work untouched. To make the point, he suggested asking 100 knowledge workers at local accounting firms and businesses how much time AI saves them: his expectation is that the answers would land in the 10-to-20-percent range, not at “it’s doing everything for me.” That is Greze’s assessment from the interview, not a measured benchmark for Town.

He expects the software to get better at suggesting tasks it can take on. But saved time does not necessarily mean a worker has less to do. An executive assistant who spends fewer hours scheduling meetings or labeling travel expenses might use that time for work that requires judgment and personal attention. In Greze’s view, automation can shift effort toward tasks that are more valuable precisely because they remain difficult to automate.

He also described why a prompt box alone may not bring AI into ordinary work. People are busy, often already skilled at their jobs, and may not have the time to learn a new tool or change their routines. A chatbot that starts with no access to someone’s data asks its user to supply context manually. Town takes the opposite route by requiring connected data up front. Greze said this kind of product is more expensive to operate because it draws on many sources, a cost that does not fit every free-service business model.

Even as he expressed confidence in AI’s potential, Greze said its effects on day-to-day work remain limited outside areas such as customer support, coding and some creative tasks. The difference between broad claims about the technology and what most workers experience is one reason he expects adoption to take years. For Town, the practical question is whether the assistant can make connected data useful enough that users accept the setup and keep relying on it.

What the assistant does, and what people pay

Town’s current offer includes meeting preparation, email drafting, scheduling and help with personal tasks. A meeting briefing may collect context about attendees and the subject of the discussion, then present it shortly before the meeting. Newton said the briefings anticipated needs he had not yet thought to ask about.

Greze said the value is not always a simple count of minutes saved. A user might have scheduled a meeting weeks earlier, forgotten the details and read Town’s briefing a couple of minutes before joining. If the briefing helps them participate more effectively, it has made the meeting better even if it did not shorten the workday. He acknowledged that routine tasks such as replies and scheduling may become standard features over time, while arguing that customers already find value in them.

Prices reflect the cost of providing the product. Greze said Town has a $15 starter plan with limited features, while most users pay $49 to $59 per month. He has been concerned that the price could be a barrier, particularly for parents who use the service to manage family logistics. One customer told him she paid $75 for a manicure at least once a month and valued the time Town saved her more. She described handing the service a PDF of children’s sports practices and games and asking it to add them to her calendar; she estimated that avoiding those chores was worth $600 a year to her.

That customer’s comparison gave Greze a way to think about willingness to pay: people decide whether the work removed from their lives is worth the subscription. He said he would like to make Town cheaper, but tied the current price to operating costs. He also characterized customer retention and referrals as signs that users are finding enough value to continue and recommend it. Those are company-reported observations in an interview, not independently verified figures.

Town’s paid model also shapes its privacy argument. Greze said the service does not depend on advertising, product recommendations or selling suggestions about what users should buy. He described Town as an agent working for the person who pays for it. That commitment matters because the system’s usefulness depends on access to personal information, but the business model alone cannot answer questions about storage, access controls or mistakes.

Data handling and mistakes

Greze said Town does not copy and reindex every email on its own systems. Instead, it samples email, calendar information and other connected sources to make a wiki of roughly five to 20 pages. He described that wiki as an abstracted map: when a user asks for help, it points the system toward relevant messages or calendar entries, which can then be brought into the active session. Town also uses live search through connected services such as Gmail, Calendar and Notion to find information relevant to a particular question.

According to Greze, Town deletes session data after 15 days. He said one exception is a special type of session that can retain information the user has asked the service to remember. The company’s other safeguards include encryption and a restriction on internal access. If a user sends a support request, a checkbox asks for permission to inspect the relevant session for debugging; Greze said that without consent, the support team cannot see its contents.

Town also says the relationship between an employee and their townie should be private, including when the employee uses it for work. Greze said the company’s enterprise agreements bar employers from reading workers’ conversations with their townies, and that the company has no way to provide those conversations to an employer. He contrasted those exchanges with workplace email and documents, which may be accessible to the employer that owns the account or system.

Privacy is only one way an assistant can fail. Greze described security risks, where an agent could be tricked into sending private information somewhere it should not go, and what he called “egg on face”: a visible mistake that leaves a user embarrassed. Town requires human approval when a chain of actions would send information outside the service, he said. It also does not give the agent a tool to send external emails automatically. Drafting an email leaves the final decision with the user.

Ordinary errors can still damage trust. Greze cited a scheduling mistake involving a daylight-saving time change, which left a meeting an hour off. He said Town tries to let the assistant act when it has confidence, but ask for approval when the task requires too many uncertain steps. A useful assistant needs to make those limits visible before a user relies on a flawed result.

Meeting research created another failure case. Town once prepared a briefing about the wrong person because an online search found someone with the same name and a similar job. The user then questioned the reliability of other briefings. Greze said the product now presents both possible profiles when it cannot tell which person is the right one. That change illustrates a broader design principle: admitting uncertainty can preserve trust better than presenting a guess as settled information.

Work that gets automated, and work that remains

Town’s users include executive assistants, a group Greze said is among the product’s three largest user groups. He said assistants may appreciate help with scheduling and expenses, while valuing a first draft of an email written in the voice of the person they support. The draft still needs human editing before it is sent.

There are two plausible effects on the job. If software reduces routine work, an assistant can spend more time on complex, high-value support. At the same time, a company might expect one assistant to support more people and hire fewer assistants. Greze said he cannot predict which effect will dominate. He feels responsible for considering the consequences of the products he builds, but said his role is to make a product people will pay for because it improves their lives.

He offered a similar example from medical scheduling. Some Town users help arrange appointments and procedures, and remind people when changing schedules affect when they should take medication. Automating calendar work and reminders could leave more time for conversations with people facing stressful changes. In Greze’s account, the mechanical tasks were necessary, but they were not the core human value of the job.

Greze is optimistic that today’s AI can take repetitive work off people’s hands, but he stopped short of claiming that the long-term employment effects are clear. He compared those changes loosely with the decline of work associated with horses, while acknowledging that automation will not benefit every worker in the same way. His example points to a real tension in productivity software: making a role more efficient can improve the work, reduce staffing needs, or do both.

Town’s next test is to turn its personal dossiers into a team resource without making private information available by default. The product already shows how connected data can produce useful briefings and task support. A shared wiki would extend that model across colleagues, where the potential value grows alongside the cost of an error. For teams considering this kind of system, the key details to watch are what data enters the shared library, who can inspect conversations, how the assistant handles uncertainty, and whether users can see and correct the profile it builds about them.