Skip to content
Canonical

Lane A Workshop Feedback

Feedback - lane-a-workflow-inventory-strawman.md

Section titled “Feedback - lane-a-workflow-inventory-strawman.md”

Validation points

Section titled “Validation points”
  • All items where validation was required have been reviewed and the assumption or default is ratified. I’ve provided responses below to four items where a response appeared to be required, which may not have been covered in the questions or where a default wasn’t provided:
    • [VALIDATE: does this role exist as a distinct person at Phew?] - Yes
    • [VALIDATE: weakest-evidenced persona — confirm a real counterpart exists before investing] - For Phew, this is a hat, but for future clients, this will be a person(s).
    • [VALIDATE: who owns guides at the client?] - Matthew as ultimate owner, but maintained by the wider team.
    • [VALIDATE: is argument-quality checking wanted as tooling, or is this purely editorial craft?] - Yes.

Workshop agenda question responses

Section titled “Workshop agenda question responses”
  1. §1.2 ranking still holds. In terms of O3 (trust maintenance), this was a big driver for pivoting to cocoindex for the pipeline, and for v1, ensuring we start with a controlled ingestion point (local fs), where changes to underlying content are automatically picked up, and where for now, we can ensure that we use an ETL-approach, for adding new content to the local-fs. For W2.3, and other examples, my view here would be that ID-71 becomes the task that we use to structure our approach, refine and define. And then where there are specific use cases, especially if they don’t already exist, then these themselves would be their own task, requiring their own spec chain and implementation subtasks. Rather than being about v1, which predominantly focuses on the canonical pipeline implementation. The AI tooling work should be completed on a prioritisation basis and logical groupings based on that priority.
  2. Agreed, ‘hats’ aligns more than people. This also aligns closer to what an AI-first future will realistically be, where more employees become “generalists”, able to work with AI to achieve more across a wider spectrum of tasks than they previously could.
  3. In terms of what should be headless at launch, it would make sense to use the /brainstorming skill here, so that you and I can refine the requirement. Also, two clarifications, unless I’ve misunderstood something: (i) headless would presumably also mean managed agents, rather than just MCP completable tooling? Also, wouldn’t MCP + Skills essentially create a form of headless agent from Claude Desktop/.ai/CoWork, in the sense that the MCP tool provides access to the external platform, and the Skill is similar to a system prompt, in terms of providing detailed instructions, enabling work to then be completed? (ii) a key aspect of headless is also to ensure ease of connectivity with other sources, both incoming and outgoing, as the world becomes more agentic.
    • O1/O4/O6 reads + W5.6 + W9.3
    • O4 (but widen beyond just KH, reorient me)
    • O6 - Needs more consideration on how best to simplify and approach - would a “layers” approach work, in terms of e.g., “here is the data you have overall”, “here is the quality of that data”, “here is how you could use it today”, “here are the gaps”, “here are the opportunities”.
  4. The main user concern today is with trust and reliability of outputs. Valuable here would be utilising the new AI evaluation setup, and the ongoing feedback loops, in a way that could build trust, and lead to opportunities where auto-apply could be switched to. Audit would be valuable here, and so something like Raindrop could likely be a valuable addition for surfacing metrics.
  5. Own task for onboarding - local first. At least until we build confidence in the system, we need to be able to gate the data that is entering the system. And something that we outlined in the related documentation that was just reviewed was that at least for now, we can set the structure for how we would want documents to be organised on a local file server and how they’re ingested. We’ll then, using our first client as the testbed, start to evaluate how we further integrate data into the system. For example, without the right checks in place we wouldn’t want to just connect to Notion and a huge amount of someone’s personal notes be ingested into the system without us being certain that our pipeline and functionality handles these effectively. Instead, one of the wider aims for the platform is that along with improving people’s ability to work effectively with AI, we also want to be able to help them start to structure their data in a way that ensures AI agents are able to work effectively with that data. So things like building out the ontology customised to a particular client and working that pipeline with their current documentation and helping them move to a data structure that can then be easily managed and maintained.
  6. Unless if there are clear examples in the outlined workflows, then my leaning is for a single outcome shaped find entry point, at least when it comes to things like MCP tooling.
  7. This is absolutely an area that’s been overcomplicated and I think ties in with what I’ve outlined initially for question 3 in relation to O6 - we need to focus on getting the basics right, and making simplifying the approach to resolution - “where are we exposed” and “what’s in my queue” are a great place to start, along with then utilising HvC/HA to resolve these e.g., gaps/issues identified, suggestions for resolving these highlighted in the platform and also via MCP App (“Draft content for X”, “Discuss options for Y” etc.) with the level of AI involvement flexible e.g., for certain tasks, HA could complete work in the background, and surface for sign-off, and for other tasks, the standard two-way thinking partner approach is triggered, utilising Skills.
  8. Yes, completing-forms is the concept to carry through, and W2.4 therefore also folds in.
  9. W5.2 (sales triggers) first, and the next would be W5.3 (marketing pipeline). Client data resides in HubSpot, which our first client has already connected to Claude CoWork, via MCP. For whether or not W5.2 should be its own task, see the wider ID-71 suggested approach in Q1, but the other question would be whether this falls naturally under the sales proposals work which has so far had an element of being spec’d but I haven’t yet reviewed these and I’m not sure if they’re suitable for what it is that we’re looking to achieve here.
  10. What’s important is that we don’t get caught up in working to “ceilings” - better to have a structured approach for determining whether a tool is required, and if so, the best way to implement it - I’m exaggerating to make a point, but if there are 50 headless agents in the background, all completing tasks which deliver value and a user only ever uses one MCP tool which provides them insights and the ability to take or defer action, then whilst this looks like 51 tools, it’s considerably more effective than 58 MCP tools, which both Claude and the user would need to regularly get to grips with. Enabling progressive utility of AI-tooling, as trust increases, based on clear quality metrics, will be key to ensuring we build and integrate the right platform tooling. The synthesis does well at highlighting this with the concept-over-artefact principle - “verdicts attach to outcomes, not to tool names.”