Category: All

  • Using code janitors to untether the vibe coder on your team

    The temptation to push a huge PR after a productive session with a coding agent is very hard to resist sometimes. It may matter less for a solo project, but a team working on a mature codebase in a professional setting may reject it and for good reasons. Nobody wants their core development environment flooded with complexity, risk and waste.

    Trusting AI contributions outright is problematic, but relegating agents to only handling low-risk tasks is not the answer either. There must be a way to introduce cleanup into the process so vibe-coded work can be treated as a first-class citizen.

    Why not create a workflow that solves for mess, like a code janitor? 

    What I’m looking for is a feature that enables me to contribute code safely and reliably and, crucially, not embarrassingly, after exploring an idea with a coding agent that I want to introduce into the main repo.

    GitHub’s Copilot agents can handle tasks and workflows, but I want more oversight of the agents’ behaviors. Building the hand-offs, auditing, and reporting on GitHub’s own primitives gives you more options and visibility over their activities and should feel more like working with a real team of contributors. 

    I’ve been experimenting with this with Open AgentOS. After creating a PR the agents scramble around to make sure everything is copacetic, running tests and reviewing code. They then report their findings, leaving receipts as they go along.

    The initial implementation of this janitor idea is optimized for observability. After creating the PR, a Watcher agent sees the new PR with no issue or plan and immediately triggers the orchestration flow. The Archaeologist agent picks it up and reconstructs intent from the code, creates an issue for it, and links the PR to the tracking issue. The Reviewer agent assesses adherence to scope and policies, making change requests and updating labels for the appropriate hand-off. Then the Reviewer agent leaves instructions for you in the comment, waiting for your approval on next steps which may or may not involve asking the Builder agent to work on the code.

    There are a few ways this system could evolve. For example, the system could make decisions such as whether to split up work so that it adheres to a policy or standard the team may have in place. Or it could make it easy to manage any number of arbitrary workflows that utilize the labels for state management. Or perhaps it could use the receipts to learn from itself and tune the system.

    I’m using the AgentOS configuration in an experimental repo as a reference app here https://github.com/open-agentos/agentos-pmqs.

    You can see the agents walk through the process in this PR https://github.com/open-agentos/agentos-pmqs/pull/8

    • Saw the PR, created issue #9
    • Reconstructed intent from the diff, wrote it up
    • Labeled it for handoff
    • Told me what to do next
    • Read my approval, relabeled for Reviewer
    • Built a review checklist, worked it line by line

    Finally, it reported out a receipt showing the tokens used, duration and total cost. That data allows me to do performance analysis for iterating on the system, as I’ve talked about here.

    A fully integrated LLM-and-harness stack like Claude Code will be able to work in similar ways and perhaps feel more like an extension of the individual driving the work than this more deterministic and structured approach I’m working on. But I’m starting to see how bespoke agent operating systems may be more valuable in a professional team setting where the risks are higher, reliability matters more, and being able to monitor and improve the system itself is non-negotiable.

  • Introducing Open AgentOS

    Almost every technological leap I’ve ever taken has been preceded by something Jon Udell articulated before I got there. Today is no exception:

    “I dislike the phrase “human in the loop” because it cedes authority to the machines. Let’s flip the narrative. It’s our loop, we work the same way we always have, now we recruit agents to join the team. An agent-assisted process need not be a black box that takes in prompts and emits features.” 

    It’s not just the idea of the shared experience with the loop or the concept of “visible workings”, it’s also the idea that we’re “recruiting agents to join the team”

    After proving out some ideas (see more here, here, here and here) around using GitHub as the shared workspace for building software with agents and managing my AI team, I’ve extracted and published the configuration as a re-usable framework. It’s called Open AgentOS:

    https://github.com/open-agentos/spec

    Why create a spec for an open agent OS?

    The software development that I enjoy most is when it’s a team sport. Solopreneuring is certainly exciting, too, but there’s nothing quite like leaning into a challenge with the people you trust and depend on every day, everyone knowing their role, fitting each other’s work together, and coming out the other side with something only you and your team could’ve done.

    Agents are becoming part of that dynamic, but it can create some friction. To carry on with the team sport analogy, you wouldn’t want to have a super talented member of the team skipping all the training sessions and team meetings. That player may help you score more points when they show up to the game, but the achievement is hollow and temporary, not a systemic change that builds a high functioning team that wins consistently.

    I want to know what my AI agents are doing and how they’re doing it. I want to see where problems might be forming in the system, what costs are accumulating, and where improvements can be made. It’s not hard to instrument current systems such as GitHub to report out the data that will show you what’s working and what’s not. It takes a few minutes to configure. 

    Once it’s setup the experience is a lot more like working with a team. You can think about what tools you want to recruit into your environment and integrate them without having to buy a whole new product or signup for a new service. It should just work the same way you’ve been working for the last several years. …but with some new players on your team. 

    The spec covers how Open AgentOS works in detail. In short, GitHub acts as an agent operating system. Issues are used to manage state and trigger different agents to contribute when called upon. You can look across your team of agents and their work using the Projects feature. And everything outputs raw receipts and detailed event data that you can use for analysis. 

    The system is designed with a few principles in mind around observability and agent accountability, and it is extensible so that you can bring your own agent and add your own plugins. It’s intended to operate with any stack so you can make it work however, wherever you want. 

    Anyone interested in joining the team here is more than welcome to contribute. I’d love to see some new capabilities around dashboards, non-github environments where this could also work, and plugins for other use cases and integrations. 

  • Hidden costs of agent loops

    In the race to build better agent loops it’s easy to ignore token waste as a problem. Getting an idea into a working state is so cheap and easy that the pressure to spend and compete far outweighs concerns about waste.

    Any project that gets past that initial implementation will need a reliable way of managing the way things get done, and that means knowing how much it costs. When you start counting your tokens against turns, tool calls, errors, failures and so on the waste can suddenly look pretty alarming.

    While experimenting with using GitHub as an agent orchestration harness (1, 2, 3) I found that the blended cost per issue rate was reaching $3.43. Excluding the stalled issues, the rate is only $0.61 per issue. That seems much more reasonable, but is it realistic at a larger scale?

    Digging deeper, I found that the cheaper features change 1 file within 10+ turns, things like documentation updates. Some were operational runs that handled some issue or PR management work. In most cases, they were unnecessary or low impact. 

    The work where an issue adds or updates 2-3 files within 40-50 turns costs about $0.99 on average. Those issues were the ones that introduced capabilities like rate limit handling, generating scripts, writing tests, etc. 

    The problematic issues that killed my cost per issue rate were things that introduced change-requests during review or that hit an error and looped through changes to address it or that inflated the context early in the process. 43% of my total spend over a week went to these bad issues, so I’ve been implementing max_turns, max_attempts, token_count_warning and things like that.

    The magnitude of these cost per issue rates starts to become more meaningful when talking about more serious product development. Processing 10k issues at $3.50 per issue costing you $35,000 while knowing that you have wasted $25,000 of that pot on failures and errors would be very disappointing. Larger organizations running multiple projects with multiple teams would have to reconsider what they’re doing if those ratios remained that poor at scale.

    I only know all this because I’m instrumenting event traces that are logging token counts, turns, and outcomes, and running some lightweight analysis over the data. Otherwise I would be looking at my service provider dashboards and thinking, “Hey, the costs are looking pretty manageable.” The truth is that those costs are masking a lot of inefficiency. 

    Provider dashboards show you spend, not waste, and those are very different things.

    The context that makes cost data meaningful lives in the orchestration layer, not the API. If you’re not logging it there, you’re not managing your agent system. You’re just paying for it.

  • GitHub-as-AgentOS, Part 3: Feature layer oversight

    Missing from the agent loop discussion is the product view of the system doing the looping. Where is the insight into how a project is progressing? Anything happening above the agent loop level is the responsibility of an orchestrator function, but what does that workflow look like? How do you steer the orchestrator and monitor that the agent loops responding to it are achieving the larger goals of the project?

    After exploring ways to use GitHub-as-AgentOS (Part 1, Part 2) at the agent loop level, I figured the Project Board feature might solve this problem, and I think it does. It gives you something closer to a command center with a view across the work that is in play. 

    With webhooks triggering on issue label changes you can assign agents to do reviews and implement change requests and push code or whatever you allow them to do. GitHub Apps let you scope each agent’s identity and permissions independently, so a “reviewer agent” can’t accidentally merge, and a planner can’t push code. A “planner” agent can then spin up new sub-issues in a larger feature and label them appropriately to trigger getting the work done. 

    And here’s where it gets really useful from a higher level… the collection of issues for a feature can be monitored via a Kanban-style view or a Roadmap scheduling view. What are my agents working on right now? And I don’t mean “which tool call did they just make?”. I mean, “what is the status of my feature?” Are there a lot of issues to process? Which ones are done? Which are coming up next? Which are stuck? It can make it clear that, for example, three issues merged overnight but one got blocked and is awaiting a decision from the orchestrator agent.

    The tool stream data breadcrumbs that AI agents leave along the path from start-to-outcome can shine a light on things like which models are achieving the best balance between cost and result, indicators of token wastage, effects of pipeline changes, etc. That’s the foundational data this builds upon. 

    We can aggregate the data at the project level. That data may show that certain workflows give better outcomes for certain types of features. I can A/B test processes as well as models, such as a planning-led process with acceptance criteria or a short-burst implementation with code-cleanup agents or a documentation-heavy investigation informing a PRD and so on. 

    This feature-level observation layer over AI coding is starting to give me confidence as a product person that I can use agents to drive an outcome that has more moving parts and pieces. I trust it to build things, but without oversight of what’s actually happening and what’s been done and not done, it’s hard to trust it to build important things. GitHub-as-AgentOS is gradually proving to me that the solution is in the tools we already use every day.

  • GitHub-as-AgentOS, Part 2: Telemetry opens the black box

    GitHub-as-AgentOS opens a whole suite of analytics options that make it possible to steer the ship instead of just closing your eyes and hoping for the right outcome. By adding some event logging to the agents’ activities simple dashboards can be build for tracking things like cost per turn per agent, context inflation, pipeline cost over time, etc. 

    In my case, the dashboard pointed to a problem in the pipeline that no code review would’ve found.

    The reviewer agent was doing it’s thing, running through acceptance criteria, which is what it’s supposed to do, but the chart showed outsized token consumption vs what I would expect of it. The whole idea of the reviewer agent is that it shouldn’t need a huge amount of context to verify a file has changed as expected or that a script’s output is valid.

    I can also see what I don’t know.

    My reviewer is simply approving code or sending it back with change requests. I don’t know whether the quality of the code is good or whether the solution is sensible. Introducing some scoring and qualitative rubrics for my reviewer agent to use would give me a sense of how effective my builder agent is at solving certain problems. It could give me a sense of which LLMs are better for which types of challenges. In the future, it might be smart to introduce multiple builder agents per run. Then their solutions could be compared and graded before choosing which to merge down, feeding that knowledge back into the system so it learns.

    The insights are helping me to prioritize optimizations.

    The dashboard shows that context inflates more than 10x from the first turn to the last, and the problem is getting worse with each new issue. Digging into it further I can see that introducing compaction steps in the builder agent’s workflow could drop my costs for that agent by an estimated 30%, maybe more.  

    I might also introduce an escalation moment in any run that exceeds $2. When it hits the $2 threshold then it could stop and ping me for approval.

    There’s more work to do around running multiple issues simultaneously and adding more specialized agents with different properties in addition to the optimizations made obvious by the event traces. But the system is demonstrating that we can know what our agents are doing and improve them in measurable ways.

  • GitHub-as-AgentOS

    The characteristics of what I think everyone is referring to by the term “Agent OS” seem achievable through abstraction by configuring GitHub as a harness. In fact, much of the Zero Trust requirements as described by Anthropic come for free this way. And with all that’s on offer via the API much of the observability challenge shifts to analysis of the data.

    GitHub-native orchestration turns the agentic black box into a machine you can monitor and tune.

    This exploration started because I wanted to use LLMs to generate questions from some complex data, but I started worrying as much about the process of building with agents as I did about what I was building. So, I separated out the repos and went down the Agent OS rabbit hole in an “ops” repo. Here’s what it has become, so far:

    Agent OS FeatureGitHub / Git MappingImplementation
    System Clock & CPU InterruptsGitHub webhooksGitHub webhooks fire events to trigger the Hermes gateway, spawning containerized agent sessions on-demand.
    Task Queue & SchedulerIssues & LabelsThe orchestrator schedules work by creating GitHub Issues and labeling them (e.g., agent:builder, status:to-do).
    Memory Registers & StateLabelsIssue and PR labels (e.g., status:in-progress, status:approved, status:changes-requested) act as registers tracking the agent’s execution state machine.
    Inter-Process Communication (IPC)Pull Requests & CommentsAgents coordinate via GitHub’s social layer; the builder opens a PR, the reviewer reads the diff and comments, and the builder responds via follow-up commits.
    Workspace SandboxingGit BranchesBuilder agents are sandboxed on feature branches (e.g., agent/role/issue-num-slug) and cannot touch production directly.
    System Gates & Security PoliciesBranch Protection & PR MergingHuman orchestrators merge code only after the reviewer agent applies the status:approved label.
    System Registry / Living DocsLiving Markdown FilesFiles like CLAUDE.md and AGENTS.md serve as system configuration registers that agents automatically keep updated.
    Audit TrailGitHub Event LogEvery action (commit, comment, label change) is timestamped, attributed to a GitHub App, and permanently stored.
    Privilege IsolationGitHub App Scoped TokensEach agent role is a separate GitHub App with scoped API permissions, creating hard technical boundaries.
    Prompt Injection ContainmentPer-Agent Context ScopeDownstream agents operate on structured metadata rather than full context, isolating them from potential injection the builder encountered.
    Anomaly DetectionLabel State + TimestampsA stuck label state is detectable via the API; unexpected bursts of commits or label changes enable rule-based alerting.



    Several interesting outcomes from this approach became apparent.

    By using the Issue as the session storage record, data can be written down for use later, and, of course, GitHub’s GraphQL API makes it very easy to collect and do post-session analysis. Having a trajectory log (which agent acted, what label triggered it, what it did, what it commented, what it committed) that is actually readable and connects outputs to its actions gives me some confidence that I’ll be able to understand problems and instruct agents on how to address them rather than using a “Fix it” prompt that turns into a huge mess.

    The problem of starting a new agent session with all the insight needed without flooding it with context becomes more manageable which could make it possible to solve harder problems with smaller, cheaper models. Collaboration gets interesting too. For example, Memory could be shared with your team on a granular level, as in, per agent per repo per milestone, and, since it’s getting versioned, you can look back at how it evolved if you’re questioning a change to the Memory.

    Introducing some process determinism in a way that feels a bit more reliable than an AGENTS.md instruction is a good thing, too. Using labels for state management is not going to be flawless. It’s easy to misfire a webhook that then blocks the whole process and maybe it needs something more robust than a retry in the gateway, but the workflow or pipeline control you get with something so simple as a GitHub label as the trigger system is much easier for a normal person to understand. Plus, in a more serious development environment you can’t just rely on the output as the proof that the system itself is functioning properly, so, even if the pipeline with the webhooks seems fragile, getting event-level data that you can track is a much more robust architecture than the “wait-for-magic” mode some agent loop systems offer.

    The centralized orchestration ideas in many agent loop systems has merit, but I can’t see how that scales as well as scoping and managing process on a per-issue basis. If the issue documentation is clear about scope, acceptance criteria, test cases, etc., and if comments are clear about what each agent has done, then all subsequent engagements with an issue can just act on an as-needed basis using the shared context in the issue, triggering each other via the labels.

    I haven’t run any evaluations, but it won’t be hard to add a tool that collects enough data to analyze things like task completion rate, trajectory accuracy, step success rate, etc. That won’t help me understand failures of reasoning or poor choices, but it will help me see where those issues may or may not be occurring. The data will be in there. I just need to build the tooling that gets it and makes it usable. Then I can run some of the agent process evals suggested by Cameron Wolfe.

    The Zero Trust requirements can be managed well this way, too.

    Every action is a GitHub event (comment, commit, label change) timestamped, attributed to a specific GitHub App, and permanently stored, so you get a rich audit trail for free.

    Permission granting can be very granular and strictly controlled if each agent is a separate GitHub App with scoped tokens. The reviewer agent can be physically blocked from writing any code. Similarly, a builder agent can be physically blocked from merging a PR to main. It literally cannot call the merge endpoint. And by working in branches their work is safely sandboxed by default.

    Then subsequent agents in the workflow can check for alignment with the goals of the issue. They can identify problematic out-of-scope changes without requiring the context used by the builder agent. So, as long as they operate on the metadata, they are removed from any prompt injection other agents may have been exposed to which makes them a much safer agent-as-judge in the workflow.

    For now, consider this a thought experiment. The pieces are all working for the most part, and the early tests are promising. My motivation for sharing it now is to see if anyone is tackling the same problem the same way or if there are lessons already learned that would save me some time.

  • Why we made Brave Today

    (Full announcement here: https://brave.com/announcing-brave-today/)

    My media diet is never going to be satisfied by a single publisher. That said, most of the publishers I like have useful apps and give me a lot of what I want. The good ones have some visual appeal; they’re timely, relevant, and a pleasure to use.

    Any publisher app is basically going to be disappointing, though because my preferred source of international political news is very rarely the source I turn to for financial coverage which is never the source I want for coverage of my favorite basketball team. And none of those will ever give me the insights I love from super niche publications about things like woodworking or classic cars.

    The aggregators are better at serving a varied media diet, but I don’t want them to know my niche interests or even my broader interests, because that would mean even more precise data about me is being harvested which I really don’t want. It’s very disturbing when you read an article and then start seeing ads about that subject everywhere you go.

    The only time I’ve ever felt like I had all the media coverage I wanted the way I wanted it was back in about 2005. When we had RSS and news readers I was able to tune my media diet using an app that fed headlines from tons of different publishers into one place. I loved adding new feeds as I discovered them. Even more than that, I loved turning off a feed I didn’t like anymore knowing that it was actually gone forever. They couldn’t retarget me or send emails or sell my data because they never knew who I was in the first place.

    Admittedly, those of us who valued RSS readers most back then were probably excessive consumers of news and magazines and blogs with a high tolerance for geekery, unlike the wider population that had no time for the fiddly interfaces of tools like Newsgator, Bloglines and FeedDemon and the frustratingly ever-increasing count of unread items, much less the confusing buttons used for adding a feed to a feed reader. Even Google Reader was probably a bit too awkward for most people.

    But that’s not to say the market hasn’t improved. The user experiences for scanning content are far better today, and the volume and variety of coverage has grown massively. We now have volume and variety within niches of niches in terms of how we interact with media, who is producing it, what they are producing, where it’s getting distributed, and how to profit from it.

    The most important breakthrough that made all this possible probably wasn’t search or social distribution. It was the adtech that adopted the service oriented architectures of 2005 and learned how to track people and target them with messaging.

    While the funding that resulted from the adtech innovations made it possible to evolve content apps and services, the deal included a massive sacrifice to our privacy on the Internet. At the time that trade would’ve seemed worth it. But it’s not worth it anymore. It’s not necessary, either.

    As Francois Marier describes in the blog post about Brave’s private CDN it’s possible for the app or provider to build a network-based service that knows nothing about the user consuming it and can’t know anything even if it wanted to.

    In our case, to be more specific, the user’s request for content from the server gets encrypted and passed via an intermediary that can’t see what the user requested but sends the request message on behalf of the user to the server. The server can see the address of the intermediary for its reply and the contents of the encrypted message, but the server can not see the user’s address or any other data about the user. The server has no idea who sent it.

    The work required to do this would’ve been total overkill back in 2005. Why would you do all that when at the time everything was clearly moving toward search and social which employed user tracking to get the most out of the ad business attached to it? Platforms and publishers wanted more data about users, not less.

    Now that platforms and publishers have all been feeding this tracking ecosystem for the last 15 years the whole thing has gone way too far, but I still want my news and links to interesting things happening in the world. Can I have it with no tracking, please?

    When a small team of us started working on a news reader at Brave a few months ago we were reminiscing about RSS readers and wishing the world still worked that way. We prototyped a concept that was initially going to use some APIs to gather headlines, but we found most of the feeds we needed to make it work. It turns out that most publishers are actually still using RSS. What a great surprise!

    Why wouldn’t they? The format is an open standard with very basic output which makes it really simple to syndicate your content (see what I did there?). Most CMS’s generate RSS feeds automatically, anyhow.

    We found the prototype to be surprisingly compelling. The only thing it needed was a modern privacy strategy and a business model. Both of those things come pretty easily to the team at Brave, and the prototype expanded into a proper news reader that we called Brave Today.

    We didn’t want to wait too long to get a version into people’s hands and see how the market receives it. So, we prioritized the user experience, content delivery, privacy controls and advertising features first. But we have our eye on a fully open RSS reader that you can configure with feeds you find anywhere on the Internet. That would complete the bridge from 2005 to today which, if successful, could democratize content distribution on the Internet again as it was before Google and Facebook swallowed everything.

    Lessons from the era are coming back to me as we progress, such as the importance of a great cold-start experience, the value of relevance and personalization in reducing the noise, constraining configuration options so it’s not confusing but offering enough to make the feed feel like your own. And then there are so many new capabilities available to us now that can make this old idea so much better this time around, particularly through mobile devices but also with other media formats. User behavior norms have evolved, as well, which means people are now totally comfortable with and perhaps even prefer having infinitely scrolling lists.

    I’m pretty sure this is going to scratch an itch for a lot of people. It definitely will in my case, and I can’t be the only one who wants a modern news reader that preserves your privacy.

  • Data pattern-hunting makes everything boring

    Digital platforms have finally become the economic powerhouses many of us whose careers have spanned a few technology waves always knew was possible.

    Among other things I’m quite interested in how their use of statistics and cohort analysis is driving conformity in society at scale. Admittedly, this is a subjective chicken and egg question, really, but it seems to me that being unique and different today is harder and riskier than ever before while the rewards for being normal become greater and greater.

    There was a weird moment somewhere around peak Simon Cowell when everyone realized we were complicit in pop music’s boringness. His show eliminates outliers to form a cohort of pretty good but mostly forgettable performers. Then we vote for the least worst one.

    This is happening everywhere. Cars all look the same. News outlets report the same news. Even fashion brands who trade on being different are literally losing their edge.

    Is there a better sign of the times than the full embrace of the color gray?!

    Guitar solos, roadsters, columnists and fashion icons reminded us that we can step out of the machine if we want to. Now we don’t even try. Instead we blend everything interesting until the mass has no distinctive color at all.

    Normalizing everything didn’t happen because of Internet platforms. It started decades before they were even invented. But the Internet platforms mastered the art and became commercial juggernauts, as a result.

    What makes them good at it? It’s too simple to say they’re good at computers. That may be true, but it’s really all about how they manage the information flowing in and out of their computers.

    Marc Andreesen was right. Software ate the world.

    The people who are looking at that data and making software that feeds the computers are assessing patterns. They’re not looking for exceptional data or data that sits outside the norm. There’s so much data flowing through these computers that they can only handle data that looks the same. They literally throw away unusual signals. They call it noise. Sometimes they call a weird data signal an ‘error’.

    It’s much easier to make sense of large clusters of common behaviors and then to focus on those clusters. If you can drop people doing the same thing through a conversion funnel and get transactions at the bottom then you have a business model.

    Startups have a lot of pressure to scale quickly, so there’s really no time to waste on the anomalies. They have no incentive for handling unusual activity other than to find a way to shove anomalies or ‘errors’ back through the funnel somehow. They are looking for normal patterns and doing everything they can to make all the data they collect fit in the same bucket.

    To be honest, I find it unfair to blame the platforms for this market dynamic.

    I remember very clearly the dismissive tones from the non-techies in the late ’90s every time an amazing Internet startup would appear, “Yeah, but nobody’s making money, yet. It’s just hype.” That went on for years.

    Then things started to work. But let’s be clear. The platforms weren’t intentionally employing nefarious data manipulation to exploit us. They were optimising ads. That’s all it was in the beginning.

    Equally, the dotcom leaders need to acknowledge their moral obligations today. Their businesses have become part of our lives. They sold it that way and we bought it. That deal needs to change now, just like their terms and conditions change all the time.

    The problem is that outliers and anomalies are easy to ignore. And until trolling or misinformation or abuse or fraud or whatever else infiltrates and distorts the normal patterns of behavior in large enough quantities these digital spaces that want our time and attention really just don’t care.

    It’s not just the bad behavior they don’t care about. They don’t care about good behavior that is non-normal, either.

    Journalism is a great example. Performance of news on Facebook declined for several consecutive months in 2017 and instead of looking at how to embrace news they turned it off. Large numbers of people valued getting news via Facebook, but the nuances of trust, a very human value, by the way, were considered too hard to address.

    I refuse to believe that these non-normal patterns are too expensive to identify and serve in a sensible way. The same machines and statistics that are so good at finding normal patterns are just as good at finding things that are not normal. But rather than build the tooling and reporting and insights that value the non-normal they build error handling systems and quantify them with negative terms.

    Can a digital business succeed by serving the outliers? Of course they can! It’s crazy to think they don’t have the creativity, manpower or computing resources to value the things that are different. They choose not to because it requires some thinking. It’s easier to encourage the outliers to behave like everything else and just ignore those that don’t.

    There’s another question about whether this trend is bad. It would be easy to argue that more people are more educated, safer, suffering less than in pre-platform history. They bring people together and create shared understanding which probably increases peace in the world on balance.

    But let’s be honest about the cost of normalizing everything and failing to value the outliers in society at large. If we want magical music like Stevie Ray Vaughan’s version of “Little Wing” and beautiful cars like the 1962 Aston Martin and intelligent perspective like Edward R. Murrow commentary then we owe it to ourselves to ensure the outliers have room to explore and push the boundaries.

    The value of a cohort should not be measured exclusively by its relative proximity to the mean. We’ll keep losing the good stuff in this world if we do that.

    Now that software has won and platforms drive the economy (and lots of other things, too) they must look at their role in the world with a wider field of vision. They need to be serious about diversity from the boardroom all the way down to the simplest line of code.

  • The deceitful promise of freedom

    There’s a very powerful essay by Hossein Derakhshan on Medium about the Internet wasteland. It’s particularly poignant coming from someone who spent several years in jail as a result of his activities online:

    “I can’t close my eyes to what’s happening: A loss of intellectual power and diversity, and on the great potentials it could have for our troubled time. In the past, the web was powerful and serious enough to land me in jail. Today it feels like little more than entertainment.

    Anyone deeply engaged in the days of blogging will relate to these views.

    That was an exciting time that seemed capable of capturing the utopia the Internet appeared to offer. If only it hit mainstream before the social networks got their claws in.

    Of course, sometimes I wonder if our memories deceive us and that the people’s struggle to break free of control was never any more attainable during the blogging days than it is today.

    Perhaps the fight is eternal, an innate anthropological prison humans find themselves trapped within, sometimes both emotionally and physically.

    I’m not that fatalistic, really. There have been many battles won on our behalf before our time that have made our lives much better than our predecessors’. And there will be other great victories won by the people in the future.

    Unfortunately, in the case of blogging, I agree with Hossein that freedom got outflanked before that revolution had legs to stand on. Annoyingly, we’re all complicit and every time we ‘like’ and ‘retweet’ we’re pumping more collective fuel into the centralized machines that defeated it.

    Being a parent is a fantastic education. Watching my kids take toys apart to see how they work only to discover they can’t put them back together is a sharp reminder of how our brains work.

    Computers, networks, phones, and social networks weren’t invented by people who wanted to control the world. They were invented by intensely curious and ambitious people who wanted to take apart ‘the system’.

    They took great pride in their David vs Goliath stories, never more brazenly than the historic Apple Big Brother ad.

    But after dismantling the status quo many of these folks have spent the rest of their careers putting the pieces of their foe back together again in their own image.

    Instead of defending the freedom they espoused in obtaining their position of power they focused all their power on securing their future for themselves, constructing impenetrable walls against the threat of a younger and hungrier version of themselves attacking.

    The promise of freedom from tyranny is a great marketing strategy for a startup. That message resonates deeply within our psyche because it is a universal sentiment.

    But sometimes it’s a lie.

    We need startups to invent better ways of doing things. We need people to lead the never-ending fight for our freedoms. We all need to be more honest about when those two things are in conflict.

  • Who is in charge of the global economy – us or them?

    I’ve always looked up to independent-minded people who can strike a balance between operating within ‘the system’ and changing it through their work, particularly when that work is in the public interest.

    Vivienne Westwood is such a person.

    I met her recently to discuss working together, and she didn’t disappoint. She began the meeting describing a world view that concerns her, one that should concern all of us. And we considered ways to use people-supported journalism to improve public dialog about it.

    The world view that concerns her is the way global power is getting rewired. She’s going to edit the next issue of Contributoria to focus on this.
    Vivienne Westwood edition of Contributoria

    It’s about international trade agreements and corporate law. It’s about the democratic process within and between countries. It’s about human rights and the environment. And it’s about those who we normally depend on to keep power in check but either can’t do it, won’t do it or fail to do it well.

    It’s a big topic with lots of nuance that I don’t understand, yet, but it is easy to see the erosion of democracy when international trade deals result in agreements that disregard laws and policies won through hard-fought democratic processes.

    Democratic principles can be interpreted in different ways, but at minimum people should have a voice in the decisions made on their behalf. And they need a role in choosing who is making those decisions.

    Everyone, including profit-motivated groups, have a right to question the law. But democracy is pretty good at making sure we know what we’re gaining and losing if we decide to change the law.

    Is democracy really at risk here?

    I dunno. I find it hard to believe we would let it get to that.

    But then again I had no idea that ISDS existed until very recently.

    ISDS is an “instrument” of international law. It’s a method or standard for enforcing trade deals, enabling companies to sue governments for lost profits. It means public policy can’t conflict with what’s been decided in the deal. ISDS ensures that the law is subservient to the trade agreement.

    In one of the pamphlets (pdf) championing ISDS in the UK they say proudly, “ISDS gives UK companies access to independent tribunals and to possible compensation when they are treated unfairly by [partner countries]. It also deters [partners] from acting unfairly in the first place.”

    In other words, “Don’t worry about international laws. We’ve got your back. And if any government gives you trouble, we’ll help you to sue the pants off them. They won’t bother you again.”

    It’s being used more like a weapon than an “instrument”.

    To be fair, an international court may in fact fuel growth if companies have some assurances that they can fight back if they’ve been treated unfairly somewhere. But only big corporates with deep pockets are going to benefit, and they will likely only use that system against smaller countries with weaker legal systems who might threaten their business model, perhaps for good reason.

    An excellent piece in The New Yorker explains how ISDS is designed to undermine sovereignty.

    “I.S.D.S. was originally meant to protect investors against seizure of their assets by foreign governments. Now I.S.D.S. lawsuits go after things like cancelled licenses, unapproved permits, and unwelcome regulations.”

    The context becomes clear when you look at what Philip Morris did when Australia passed plain packaging legislation on cigarettes there. Philip Morris sued Australia because they claimed the new plain packaging law affected their profits.

    Even more bizarrely, they didn’t have the right trade deal in place to sue Australia directly. They essentially invested in operations in Australia in order to use a different trade deal in Hong Kong that then made it possible to sue Australia.

    And somehow Philip Morris seemed to think they were the victims:

    “The forced removal of [Philip Morris] brands and trademarks by the Australian Government is a clear violation of the terms of the bilateral investment treaty between Australia and Hong Kong, and we believe we have a very strong case for actual damages that may amount to billions of Australian dollars.”

    Most democratic societies have a system of checks and balances to prevent corruption and too much power concentrated in one area. These international trade agreements are creating cross-border super-systems that are too opaque with fantastic opportunities for corruption and concentrated power.

    We are unable to vote for or against what’s being decided on our behalf by unelected people in far away places. They are making their own rules about some pretty important stuff – the environment, labor laws, culture, etc.

    The game needs to be exposed so we can deal with it. The good news is that it is becoming clearer to see with deals like the Transatlantic Trade and Investment Partnership or TTIP (“tee-tip”) and the Trans-Pacific Partnership or TPP.

    However we only know the details now because documents have been leaked, not because the information was made public.

    Even our own elected leaders are unable to get involved in the details.

    In a Politico report US officials behind TPP said that we can “expect the real horse-trading to begin now that Obama has signed “fast-track?? legislation requiring Congress to pass or reject TPP without amendments.”?

    Occupy-ers, if you were ever unsure of how you could bring your fighting spirit to something tangible, now is your moment.

    The fight against TTIP and TPP is a symbolic move we can all make together to say, “Hang on, how is this decision getting made? Who is signing up to it and with what authority? Who is going to benefit and how? What happens if we don’t like it? Who will monitor it and tell us all if it’s working or not?”

    The fight against international trade deals is a line in the sand between the new global powers and the people. Whoever wins is going to have a massive leg up in whatever comes next.

    Have no illusions about what’s at stake – these kinds of trade deals are marginalizing democracy. You have a right to know what your country is deciding on your behalf. Given the scale of these deals I think we have a right to know what other countries are deciding on our behalf, too.

    If it all feels too technical or inaccessible, then just start asking around…see if you can find anyone who understands it. Better yet, see if you can find someone who has read these agreements.

    When you come up empty you may come to the same conclusion I did which is that whatever this is all about it’s not being done for the good of the public.

    Let’s get a good look at these deals. Let’s run the proposed terms through ‘the system’. Of course ‘the system’ needs to change. It always will. It’s made by humans. And maybe there are provisions in the deals? that we should consider.

    But as it stands today TTIP and TPP and their legal weapons like ISDS look very much like people in positions of power using their advantages to lock down even more of it.

    That’s not independent-thinking. That’s not improving ‘the system’. That’s not working in the interest of the public.

    That’s worth challenging.

    There are lots of ways to get involved. One thing you can do is help Vivienne Westwood and Contributoria to fuel the public debate. https://www.contributoria.com/proposals

    At minimum, use this amazing thing called the Internet to educate yourself. This stuff matters.